I believe there are essential skills you learn as an engineer who codes. It teaches you how to structure your thinking, and the process looks something like this:

• I have this thing I want to to build.
• I have a finite set of tools that enforce a certain set of rules I must follow.
• And... go.

Coding is unforgiving. Its structure is well-defined and enforced by whatever interpreter or compiler you might be using. You are punished swiftly for obvious errors. You are punished more subtly for the less obvious ones.

Once you've mastered a particular language, you've also mastered a means of thinking. You understand how to decompose a problem into knowable units, and you learn how to intertwine those units into pleasant and functional flow. Perhaps you've figured out how to get that flow to perform at Herculean scale. There is no doubt in my mind that this is an essential and valuable skill for anyone to learn and master.

However, there is a language you could master that teaches many of the same lessons, appears far more forgiving in terms of syntax, and has immediate broader appeal.

The language you can learn is your own.

I argue that there is an essential set of skills that intersect both with writing words and writing code. Let's revisit the process:

• There's this thought I want to write.
• I have finite set of words, a target audience, and, likely, a certain article length that all serve as constraints.
• And... go.

Writing appears more forgiving because there is no compiler or interpreter catching your its and it's issues or reminding you of the rules regarding that or which. Here's the rub: there is a compiler and it's fucking brutal. It's your readers. Your readers are far more critical than the Python interpreter. Not only do they care about syntax, but they also want to learn something, and, perhaps, be entertained while all this learning is going down. Success means they keep coming back - failure is a lonely silence. Python is looking pretty sweet now, right?

The articles on Rands keep getting longer and longer, and as I'm finishing a piece, I worry, "Is it too long?" I worry about this because we live in a lovely world of 140-character quips and status updates, and I fret about whether I'll be able to hold your attention, which is precisely the wrong thing to worry about. What I should be worried about is, "Have I written something worthy of your attention?"

Writing is the connective tissue that creates understanding. We, as social creatures, often better perform rituals to form understanding one on one, but good writing enables us to understand each other at scale.

Now... go.

After a few minutes of looking around your tiny space, a calm yet creepy electronic voice begins speaking. The voice explains that you're part of a testing program, and a moment later a door-sized, orange-tinged portal opens.

Portal, developed by Valve Software in 2007, is a first-person puzzle-platform game where you're running around with a gun that shoots... doors. The handheld Portal gun allows you to create a doorway by placing both an entry and an exit portal. These portals can only be created on certain types of surfaces, and only a single portal pair may exist at a time. Using a combination of these portals, your beloved companion cube, and your brain, your character will experience a series of puzzles in test chambers where the goal is simple: get out - don't die.

That's the literal minimalist description of the Portal universe, but it explains little about how you'll survive that universe or what makes it fun. To understand the universe where Portal exists, you have to play it, and then you'll discover two things: it is a wildly entertaining place, and, while it is a game, it's a game full of well designed lessons that teach you how to learn.

The First Universe

Portal is a nerd fantasy. You've got this gun and when you blast a wall with it, you literally rip spacetime wide open with an entry portal. Blast another wall and there's the other half of your portal.

How. Cool.

That's the beginning of the cool and the simplest part of the game. As you progress through the increasingly complex puzzles, Portal does something even cooler. It teaches you the game, it teaches you how to improvise solutions to the puzzles, and it eventually makes you a master of the Portal gun and its associated physics -- without a single page of documentation. You learn about the Portal universe intimately, but you don't notice the learning because you're too busy playing.

Here's how...

Sandbox Learning

In addition to not knowing what the hell is going on in terms of the plot, the first time you play Portal, you have no idea how to play it. Like all games, the initial levels teach you the very basics: how to move, how to pick up an item, and how to use items to get things done. Yes, there is a heads up display indicating how to move, but it's up to you to learn. Oh look, when I put the cube on the button, it opens the door... to where? The plaques at the beginning of each level seem important, but I don't know why. Why do I feel something sinister is going down?

The mystery of the player not having a clue what the hell is going on is the initial incentive to learn. It's the desire to discover the story that situates the player in the Portal universe. It's a difficult balance to strike in designing a game or application. How much do you explain versus how much do you let them discover? Too much explanation and you get this:

Too much reliance on exploration and they may never discover what they can actually do. I'd include a great example of a game that was designed in this manner, but I can't and that's the point - you never played the game enough to understand and remember it.

Atomic Chunks of Understanding

Subsequent test chambers continue to clearly demonstrate additional rules of the Portal universe:

1. Place a cube on a big red button to activate a switch.
2. Portals have two sides. One end is blue and the other orange. You can enter and exit from either.
3. Nothing can be carried with you from test chamber to test chamber.

The discovery of these rules is paired and reinforced with increasingly complex puzzles that continue to teach the player about the increasingly foreign physics inside of Portal. What happens when I enter a portal that's on the floor, but exits on the ceiling? Which way is up? Success is not measured with points, timers, or headcrabs. Success is measured by the satisfaction you receive when you use the mechanics you've incrementally learned to solve the puzzle and exit the chamber in a not-dead state.

Testing, Testing, Testing (And the Second Universe)

As the game progresses, the increasing complexity of the puzzles introduces a bevy of hazards, including high energy pellets, goo, and turrets. The goal remains the same: get out - don't die. This is a tricky inflection point for any game: the arrival of the puzzle which is no longer a straightforward challenge, and I believe Portal's developers have solved for this moment in two ways.

First, Valve play tests the hell out their games. They are intimately aware of when a chamber is too laborious, too complex, or introduced before the player has learned the lessons they need to satisfyingly solve the puzzle in a reasonable amount of time. This is essential testing that must be performed again and again to find a delicate balance providing a sense of progress and accomplishment with just enough challenge.

This is a critical inflection point where the user is weighing the following: is the amount of investment I've made to date worth banging my head against the screen trying to figure out what to do next? An application like Photoshop doesn't do this type of testing because they know you're going to be committed to figuring out the challenge because you plunked down $700 for the privilege of owning Photoshop.

Yes, I'm going to compare Portal and Photoshop. Yes, they reside in two entirely different universes with entirely different motivations. This is about how these two universes should collide and that means what I'm really talking about is gamification. There's a reason I didn't mention this until paragraph 17 because there are a lot of folks who think gamification means pulling the worst aspects out of games and shoving them into an application. It's not. Don't think of gamification as anything other than clever strategies to motivate someone to learn so they can have fun being productive.

See, whether you're developing a game or an application, you want to your users to experience...

"The Moment"

Inevitably, you're going to need to make a split-second decision in Portal. The floor will literally be vanishing from under your feet and you'll have no time to consider your options; you will just improvise. It's these moments of well-informed improvisation that I believe are Portal's greatest accomplishment and best design. See, while you were busily having fun you had no idea that you were becoming an expert in the ways of the Portal universe. You now have experience using each of the individual tools and their behaviors to be able to combine them to handle the unexpected. The result: you are now able to effectively deal with novel and unknown situations.

It's incredibly satisfying to sneak out of a tight spot by performing an action you didn't know you could do, but created instinctively because of your experience.

That's how I want to learn. Don't give me a book; I don't want a lecture, and I don't want a list of topics to memorize. Give me ample reason to memorize them and a sandbox where I can safely play. Test me when I least expect it, shock me with the unknown, but make sure you've given me enough understanding and practice with my tools that I have a high chance of handling the unexpected.

Mastery is Well-Informed Improvisation

When someone raises their hand in that design meeting and suggests gamification, you have my permission to stand up, walk over, and poke them in the eye. But just one eye. While it's likely they are merely parroting a buzzword they heard from someone else, it's not pure buzz. Games like Portal have something to teach anyone interested in the motivation surrounding learning.

A video game has a very different goal than Photoshop. A video game is designed to be pure entertainment, while Photoshop is a tool by which you get work done. A game designer knows that if a game isn't both immediately entertaining and usable, the folks sitting in front of the Xbox 360 are going to stand up, toss their controllers on their beanbags and declare, "Screw it." Worse, they are going to tell every single one of their friends about this gaming disaster because they feel stupid for wasting their time and money on something that was supposed to be fun, but turned out to be lame. This is game death.

Photoshop's goal isn't entertaining unless you think the national pastime of bitching about Photoshop is a sport. Photoshop has no points or leaderboards because Photoshop is a tool and the perception of tools is that you must be willing to supply blood, sweat, and tears in order to acquire the skills to become any good at using them.

Bullshit.

Make a list. Tell me the number of applications you use on a daily basis where there is a decent chance that you'll end up in a foaming at the mouth homicidal rage because of crap workflow, bad UI, and bugginess. Is Photoshop on that list? Yeah, me too.

The plethora of online Photoshop tutorials demonstrate its power and its flexibility, but I believe they also demonstrate its poor design. Think about it like this: what if each time you plunked down in front of World of Warcraft, you had to spend an hour trying to remember, wait, how do I play this?

Great design makes learning frictionless. The brilliance of the iPhone and iPad is how little time you spend learning. Designers' livelihood is based on how quickly and cleverly they can introduce to and teach a user how a particular tool works in a particular universe. In one universe, you sport a handheld Portal gun that cleverly allows you to interrupt physics. In a slightly different universe, you have this tool called a cloning stamp that empowers you to sample and copy any part of a photo.

Both are concepts easy to initially understand, but eventually tricky to master. One comes from a game and another comes from an application, but the universes and names aren't important. When you master either, they both feel like magic.

Game designers have a different set of incentives to make their tools easier to learn via sandbox and atomically chunked learning. They may obsessively play test their games looking for user frustration earlier, but whether you're leaping through a portal or creating masks of transparent elements in Photoshop, both use cases strive for a moment where you can cleverly and unexpected solve a seemingly impossible problem on your own.

Game designers and application designers might exist in different universes, but there is no reason one universe can't teach the other.

As you might have noticed, I've recently made a few design changes to the site. I'm honored to participate in Hoefler & Frere-Jones private beta for their forthcoming web fonts offering.

Frequent readers will appreciate and understand the use of my beloved Sentinel for headlines as well as the revised header, but I believe the bigger impact is where I hope you spend most of your time - the body typeface. H&FJ's screen version of Ideal Sans, for me, is a joy to read especially on the iPad's Retina display. I can't get enough of the whimsy of the numbers (1234567890) or the calm clarity of the small caps.

If you see anything wrong, please don't hesitate to drop me a line.

10 years. 451 entries with 6500+ comments. I'd like to thank the readers of this now typographically-enhanced corner of the Internet. The only reason I'm here is because you keep coming back. Thank you.

At the time, Kahn was not only navigating the integration of Ashton-Tate, he was in the midst of moving the product suite from DOS to Windows. All the products were complete object-oriented rewrites and they were running late. Years late. At one all-hands, he explained how he wanted the company to think about itself. Recounted from a story in the LA Times from 1992:

... Kahn was reading a dense history of Central Asia a few years ago when it struck him that many of the nomadic tribes of the steppes were actually far more ethical and disciplined than the European "civilizations" they were confronting.

They were austere and ambitious, eager for victory but not given to celebrating it. They were organized around small, collaborative groups that were far more flexible and fast-moving than the entrenched societies of the time. They were outsiders and proud of it. They were barbarians.

Kahn's thinking regarding "barbarians" was prescient. It not only partially inspires Agile and other lightweight software development methods, it reinforces a theme big companies are often unintentionally trying to forget: hacking is important.

"Hackers Believe Something Can Always Be Better"

Facebook doesn't want to be a big company. Like Google before it, Facebook took the time to carefully document the reasons they were not intending to become a traditional company in their S1 filing, and while this letter is positioned to the future legion of investors, the letter is a recipe for Facebook employees:

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it -- often in the face of people who say it's impossible or are content with the status quo.

Facebook is worried about the growth paradox, which goes something like this: The end result of successful hacking is product, and that product needs to grow by building more things. The more you grow, the more things you have, and the more you need people whose job is simply to coordinate the increasingly interdependent building activities. These people, called managers, don't create product, they create process.

Hackers are allergic to process not because they don't understand the value; they're allergic to it because it violates their core values. These values are well documented in Zuckerberg's letter: "Done is better than perfect", "Code wins arguments", and that "Hacker culture is extremely open and meritocratic". The folks who create process care about control, and they use politics to shape that control and to influence communications, and if there is ever a sentence that would cause a hacker to stand up and throw his or her keyboard at the screen, it's the first half of this one.

The growth paradox is that the chaotic means by which you found success might become distasteful to those you hire to maintain and build on that success. Once they've established themselves, they will point at the hacking and ask important sounding questions like, "What is it they are building?" or "How does this poorly defined thing fit into our overall strategy?" They will label these hackers "disruptors" and they are 100% correct.

Hacking is disruptive, and whether you code software, write books, or film movies, I believe bringing anything new into the world is a disruptive act. By being novel and compelling, the new is likely to replace something else and that something else isn't being replaced without a fight.

Reasonable people are often scared by the new. This is because reasonable people are not Barbarians and they are not hackers. They appreciate the predictable, profitable, and knowable world that comes with a well-defined process, and I would like to thank each and everyone of them because these people keep the trains running and on time. No one likes Barbarians because the Barbarian strategy is one at odds with civilization. By definition, a Barbarian, a hacker, is building on a strategy that is at odds with the majority.

It's awesome.

Facebook's letter documents its core values: focus on impact, move fast, be bold, be open, and build social value. And as I read those bullets, I see two people at the table defining them. A high impact, fast moving and bold Barbarian who couldn't care less about the Biz Dev guy who is arguing for being open and building social value.

Both people are essential to a business thriving, but only one of them knows that hacking is important.

"Where's Dieter?"

Apple solved the disruptive hacker problem by hiding it, and it starts with a question:

"Where's Dieter?"

"He moved to another project."

"Uh, he has 32 open radars and we've got two weeks until Feature Complete."

"He moved to another project."

"Ok, what project?"

"I don't know."

It happens quietly, but the projects that could be the most disruptive to the company begin in silence. Someone, somewhere has a bright idea and a handful of talented engineers are whisked off to a different building behind a locked door. Their status is "elsewhere" and their project is "need to know."

Having never sat with one of these projects, I can only infer how they work, but when you see the results, you know for certain - these guys and gals are hacking. Their projects are the definition of ambition, you've never heard their names, they are small and fast-moving, and they are outsiders in their own company. Sound familiar?

Now, I don't believe the secret projects are entirely about preventing disruption, there is a large marketing component. The return of Steve Jobs was the returning of marketing and a project being secret was less about secrecy and more about marketing. Steve wanted to be the first guy standing in front of the entire planet telling you the story: "You are not going to fucking believe what we've done."

Yes, there is internal jealously about the teams performing the wizardry that resulted in products like the iPad, the iPhone, and AppleTV. There are people wondering, Why wasn't I invited to the hacking? Yes, this did create some elitism, but, for better or worse, the secrecy kept this discussion out of the mainstream.

The secret projects at Apple are institutionalized hacking. They are places of elsewhere where the engineers don't have to worry about being Barbarians because everyone there knows hacking is important.

Unintentionally Forgetting What It Took To Get You There

The story of every company begins with a clever hack. Pick any company, read its history, and I'm pretty sure there will be a well-documented origin story that will define its beginning and involves someone building something new and possibly of unexpected value. What isn't documented is the story of every moment before where everyone surrounding the hacker asked, "Why the hell are doing you that?", "Why would you take the risk with so little reward?", or "Why are you wasting your time?" What's not documented are the nine spectacular failures the hacker survived before they built one success.

The well-intentioned people who arrive after the initial success of the hack don't know of a world without it. They assume its existence and are tasked with growing the company around it. Don't for a moment think I don't value these people, because I happen to be one of them, but I am also intimately aware that the people who grow the company are not same people who found it.

A healthy product company is, confusingly, one at odds with itself. There is a healthy part which is attempting to normalize and to create predictability, and there needs to be another part that is tasked with building something new that is going to disrupt and eventually destroy that normality.

Failure to create some form of predictability will result in chaos. Failure to create some sort of well-maintained Barbaric chaos inside the company guarantees that a fast-moving, ambitious, risk-taking and ruthless someone else - someone outside the company will invade, because they know what you forgot: hacking is important.

However, these devices are expensive. In the US, the carrier supported 32GB iPhone 4S is currently $299 and the 32GB iPad 2 is $599 - both prices feel well above your average impulse buy. This is why I think it's no mistake that the two devices' release dates are as far apart as possible on the calendar given the yearly release cycle. This gives you the maximum amount of time to forget how much money you just plunked down on the latest bright'n'shiny.

It's a strategy that has normally worked brilliantly on me, until the arrival of the iPad 2. It wasn't that I didn't covet the slim stylings, I just didn't feel like I'd yet gotten my money's worth with my original iPad by the time the second iPad arrived. When it did, I carefully held it in my hands, drooled a bit on the black Smart Cover, and considered the question, "Is it worth it?" and discovered the answer was, "No". Interestingly, this answer did not change over time. Perhaps a function of the iPad's price point? Release date? Feature set? I don't know.

What I do know is that barring an unexpected post-Steve-Jobs apocalyptic design disaster, there is no way I won't be purchasing the forthcoming iPad 3, and following is a prioritized list of the features I'm looking forward to considering.

Features I want:

Retina display. You generally hold the iPad farther away from your face because of the larger form factor, which is why I don't think I notice the difference switching between the iPhone's Retina display and my iPad. But I'm fully expecting to be dazzled by the shine of Retina's double pixel density. I believe the Retina display will be your Holy Shit moment with the iPad 3. This will be the feature you'll be showing your friends.

Snappiness. My measure of CPU and graphical processor speed is completely based on feel. The test is, "When I perform a common action is it faster or slower?" Slightly faster is not snappy. Snappy is measured in a word: "Whoa".

As much battery as possible. Rumors are pegging the iPad's shell as being ~0.81mm thicker than the iPad 2. My hope and belief is that every single millimeter is being stuffed with additional battery. I'm fine with a reasonable amount of heft as long as I'm getting impressive battery life. Using the initial iOS for the iPhone 4S, it was clear that it had a shorter battery life. It's better with later iOS releases, but my impression is that it's still not as good as my prior iPhone. My fear is that the combination of additional processing and graphical power is going to weigh heavily on battery life. Via whatever my final usage patterns are, if I need to charge the iPad more than once a day, I'll be disappointed.

Features I'm interested to consider:

The absence of a physical home button. My son just explained the possible appeal of virtualizing the Home Button. It's so that no matter how you are looking at it, there's a home button right under your nose. I use the Home Button on the iPhone all the time for a very basic maneuver: I reach in my pocket and feel for the front button on the phone. The Home Button instantly orients me to the location of everything else on the phone, whether it's the headset jack or the camera. I don't have the same need with the iPad, and, in fact, I like the idea that Home may always be in the same place. I would not say the same thing if the button was being removed from the iPhone unless some type of haptic magic is being deployed, which is entirely possible.

Cost. To date, Apple seems very happy sticking with their Good, Better, Best pricing structure, with the only variables being storage and 3G - pricing was unchanged for iPad and iPad 2. There are two obvious pricing pressures on iPad 3: component prices and competition.

Component price. Clearly the hardware necessary to provide the Retina display is going to cost more. Same with a new CPU and all the other whiz bang Apple shoves into the enclosure. The question really is: what's the total cost to Apple given that existing component prices continue to come down, combined with Apple's ability to write monstrous checks to the tune of, "We don't want lots of that component, we want all of it... for, like, ever, and if you're not interested, well, we'll just go build or buy our own factory. Your thoughts?"

What's the delta on cost to Apple? Even with all the purchasing muscle, my guess it's still higher.

Competition. The tablet space is Apple's. Amazon's had a foothold with its recent impressive land grab of market share in the space, but I'm very interested to see what happens in the post-Christmas quarter where, oh yeah, the iPad 3 shows up. Will Apple competitively price the iPad 3? Absolutely, but Apple is defining this category and, as such, they are defining - not reacting to - pricing.

My only prediction: Wi-fi pricing stays exactly the same at $499, $599, and $699. If there is a going to be a price increase it will be for the 4G units, and, as you'll see below, I'm not considering that option. Faced with increased component costs and increased competition, I don't think Apple is going to blink.

As for my ideal price point, that's better answered by...

Affordable storage. I've only run into storage issues on my iPhone primarily because of my Instagram addiction. This was mostly solved with my 32GB iPhone 4s. As for the iPad, its 32GB are fine, and if we're putting it all in the cloud, I'm not likely to bump to 64GB (or higher) unless it's price effective. Given my pricing guesses above, I'll happily pay $599 for my iPad 3.

Acceptable weight. The weight of my current original iPad is only an issue when I'm in bed on my back with the device on my chest. I'm likely watching Hulu and after a couple of episodes, I begin to feel the iPad's weight. This is the only time I've noticed the iPad's weight and I've taken it all over the world. The iPad 2 was almost 80 grams lighter than its predecessor, and in my informal poll of friends, they haven't complained about weight. So, close to that, ok?

Features I don't think I care about (but could be convinced otherwise):

4G. At the house, I have a Verizon MiFi and it's jaw-droppingly fast and also a complete power hog. I'm regularly getting 10Mbs downstream and I live in the middle of nowhere where Verizon fleeces me for crap DSL. I've never considered the data version of the iPad because the majority of the time I need my iPad there's either wireless nearby or my iPhone serves whatever mobile need I have at the moment. Besides, I want that larger battery powering all those pixels and processor cycles.

Camera. The iPhone is a clear replacement for a point and shoot camera. The iPad's is not. The use case for the iPad's camera is FaceTime, and for me and I'm likely in the minority here, FaceTime is a classic You-Gotta-See-This-Once feature. You demo it once and never use it again. The line I draw for the cameras is "it can't be crap."

Siri. Sure, ok.

My final wish is the hardest to define. I am not regularly using my iPad for anything substantive in my day. I use it, but I don't depend on it. Whereas if my iPhone isn't within arm's reach, I get twitchy. I don't know what combination of features might make the iPad more attractive, but I'm certain that a dose of snappiness, a plethora of the pixels, and the three subtle details that no one will predict but everyone will love could make a difference.

(Disclosure: I own Apple stock and I worked at Apple for the better part of a decade, which fulfilled a dream I had since I was a kid.)

Poorly written emails are an early warning of intense busy. Yes, I lack the time to proofread an email, but the mail is sent. At least I accomplished something. The step beyond this is when shit is truly falling on the floor, and while shit on the floor is professionally unacceptable, there used to be a point of irrational pride in my head during this situation: Look at me, how important I must be, with all the... busy.

It's this irrational pride I want to examine because hidden inside of it is an insidious red alert situation.

The State of Busy is Seductive

7:15am. I sit down at my desk, fire up my calendar, and examine my day. Six meetings starting in 45 minutes. All are compelling, all are likely to lead to progress. Good. Switch to Things and examine the backlog. I've got 45 minutes and 23 open tasks. Which of these should I prune? Which of these stay... Say, I've been meaning to call Joe for a week. I'll call him now.

7:25am. Joe and I are on similar morning caffeination plans, so the call is high bandwidth. We're done with our three topics in 10 minutes, and I'm now sporting the rush of not just completing a task, but completing it at speed. I need to parlay this intense rush -- what's next? Where else can I exceed my productivity expectations?

7:30am. Ok, now I'm rolling. I've skimmed my email and as I think of them, I'm writing tasks on a paper next to my keyboard, because I've somehow convinced myself that writing the task down on paper is faster than putting it in Things. (Huh?) No matter - all hail the rush of getting things done. The cycle continues. Another task is knocked off, a sip of coffee, and now I'm headed into my 8am with a head full of palpable busy.

The Zone is a well understood mental state where you are fully dedicated to the problem in front of you. First, you take the time to get the complete state of the problem in your head, which then allows you to make massive, creative mental leaps using a precious type of focus that is fleeting. In the 45 minutes leading up to my 8am meeting, I did not get in the Zone. However, don't tell my brain because I've worked hard to create the illusion that I am: massive amounts of data flowing about, a sense of purpose, and scads of coffee, but I am not in the Zone. I'm just busy.

The Faux-Zone

When an engineer becomes a lead or a manager, they create a professional satisfaction gap. They've observed this gap long before they became a lead with the question: "What does my boss do all day? I see him running around like something is on fire, but... what does he actually do?" The question gets personal when the now freshly minted manager begins to understand that life as a lead is an endless list of little things that collectively keep you busy, but, in aggregate, don't feel much like progress.

The positive feedback an engineer receives in the Zone is the sensation that you literally performed magic. From the complete problem set in your mind combined with your weapons-grade focus, you build a thing that you immediately recognize as disproportionately valuable. And you see this value instantaneously - that's the high.

I believe that leads and managers are forever chasing the high associated with the Zone, but rarely achieve them because their job responsibilities are in direct contradiction to the requirements to achieve it. We often lack the time to have the intimate knowledge of a problem space because we rarely have 10-15 minutes free to consider it.

The amazing set of skills we've built to compensate for this utter lack of context is impressive. You would not believe how many times your boss has walked into a meeting with absolutely no clue what is supposed to happen during that meeting. Managers have developed aggressive context acquisition skills. They walk into the room and immediately assess whose meeting it is, listen intensely for the first five minutes to figure out why they're all there, while sporting a well-rehearsed facial expression that conveys to the entire room, "Yes, yes, I certainly know what is going on here".

Like these context acquisition skills, we've also convinced ourselves that we have built a mental process that gives us the high that we're missing in our interrupt-driven lifestyles. We've created the Faux-Zone.

In my 45 minutes before my 8am meeting, I did not enter the Zone, but I am in the Faux-Zone. It is a place intended to create the same rewarding sense of productivity and satisfaction as the Zone, but it is an absolutely fake Zone complete with the addictive mental and chemical feedback, but there is little creative value. In the Faux-Zone, you aren't really building anything.

A Precious Hour

As a frequent occupant of the Faux-Zone, I can attest to its fake productive deliciousness. There is actual value for me in ripping through to my to-do list. I am getting important things done. I am unblocking others. I am moving an important piece of information from Point A to Point B. I am crossing this item off... just so. Yum. However, while essential to getting things done, the Faux-Zone is not a replacement for the actual Zone, and no matter how many meetings I have or how many to-dos are crossed off... just so... the sensation that I am truly being productive, that I am building a thing, is false.

My deep-rooted fear of becoming irrelevant is based on decades of watching those in the tech industry around me doing just that - sitting there busily doing things they've convinced themselves are relevant, but are just Faux-things-to-do wrapped in a distracting sense of busy. One day, they look up from their keyboard and honestly ask, "Right, so, what's Dropbox?"

Screw that.

Other than spending time with my family, my absolute favorite time of the week is Saturday morning. I sleep in a little bit, walk upstairs, start the coffee process, and wander over to the computer. There's a Dropbox folder titled "Latest Rands Articles" and right this moment there are 65 articles in progress there. After a brief stumble of the Internet, a precious time begins. I have precisely the right music on, in the center of my screen is a wall of words, and in that moment I'm decidedly not busy, I'm not working - I am building a thing and I need this time every single day.

Starting at the beginning of February, I made a change. Each day I blocked off a precious hour to build something.

Every day. One hour. No matter what.

Every day? Yup. Including weekends.

A hour? Yup, 60 full minutes. More if I can afford it.

Doing what? The definition of "building a thing" is loose. All I know is that I get rid of my to-do list, I tuck the iPhone safely away, and if there is a door, I close it. Whether it's an hour of Choose_your_own_adventure Wikipedia research, an intense writing session, or endlessly tinkering with the typography on the site, it's an hour well spent.

No matter what? Since I've started I've had roughly a 50% success rate of actually getting to my hour. The excuses are varied, but the data is compelling. Even at a 50% hit rate, I've written more, I've tinkered more, and, most importantly, I've spent over eight hours this month alone exercising the part of my brain I care about the most: the part that allows me create.

What would you create if you had eight uninterrupted hours - every month?

An Insidious Situation

There is a time and place for the purposeful noisiness of busy. The work surrounding a group of people building an impressive thing contains essential and unavoidable busy and you will be rewarded for consistently performing this work well. This positive feedback can feed the erroneous assumption, "Well, the more busy I am, the more rewards forthcoming." This is compounded by the insidious fact that part of being busy is you aren't actually aware that you're busy because you're too busy being busy. You have no internal measurement of the amount of time you've actually spent being busy.

In my precious hour, I am aware that it is quiet. During this silence, maybe nothing at all is built other than the room I've given myself to think. I break the flow of enticing small things to do, I separate myself from the bright people on similarly impressive busy quests, and I listen to what I'm thinking.

Every day, for an hour, no matter what.

His latest book, Mindfire, is a self-published collection of best essays from his invaluable weblog.

RANDS: After many years out of the game, you recently started working at Automattic. Why the return to industry? Was this always the plan?

BERKUN: I have always hated arrogant author/consultant types who had either never done the job themselves, or hadn't in decades (See How to Call BS on a guru). After writing 3 books and being a speaker for hire for a decade, I was becoming that guy and I knew eventually I should get back into the fold and see how much of the advice I give people I practise myself. The opposite of a sabbatical. The awesome Matt Mullenweg approached me about Automattic, and as I used WordPress for my blog, it seemed a great way to return to the front lines for a time. Since 2010 I've managed a team of designers and developers working on WordPress.com.

After being out of the game for a decade, what changes (if any) did you notice with the software development teams?

The important things are the same: do we trust each other? Are we motivated? Are there clear goals? Can we move roadblocks out of our way? As simple as those four things sound, they're rare. Always have been and always will be. As a leader, my job is to make good decisions, and if I do that, all four of those things become true. I did notice some superficial things that have definitely changed: namely that I'm old. My jokes and references get blank stares. But that's recoverable. If you watch enough YouTube videos to catch up on the references du jour, you do fine.

Your most recent book, Mindfire, is self-published. What was the reasoning behind this decision? And what were the most valuable lessons learned?

The best way to learn is to do. I'm going to be writing books as long as I'm alive and I need to learn all I can. Doing something yourself forces you to learn every angle. Even if I never self-publish again, the way I can talk to any publisher is different: I know more. The big lesson is that self-publishing is easy. The technology is amazing. Anyone can easily publish a book for not much money. There are no excuses. The real challenge is, as it always has been, writing a good book.

How has the conversation with your publisher changed?

It hasn't changed much, which is nice. O'Reilly Media has been very cool. Joe Wikert, General Manager at O'Reilly, interviewed me in a video cast, where we had a frank chat about all the related issues. Why I did it. What I learned. What I'd recommend to authors and publishers. How cool is that? He even helped plug Mindfire.

The book is a collection of essays from your blog. How did you go about picking the articles to turn into chapters?

Every 4th or 5th post on the blog has asked big philosophical questions in a fun way. Book smarts vs. Street smarts, Hating vs. Loving, or How to detect BS. I wanted to take all those posts that asked big and fun questions and fit them into a single volume focused on that kind of thinking. We made a long list of candidates, and then removed ones that didn't fit together or had no easy place in the flow of essays.

Your title at Microsoft was program manager. I think there is a lot of confusion about this role -- what's your best definition?

It's a glorified term for a project leader or team lead, the person on every squad of developers who makes the tough decisions, pushes hard for progress, and does anything they can to help the team move forward. At its peak in the 80s and 90s, this was a respected role of smart, hard driving and dedicated leaders who knew how to make things happen. As the company grew, there became too many of them and they're often (but not always) seen now as annoying and bureaucratic. In simple terms they are team leaders; good, trusted sergeants near the front lines.

Do you think there is a cautionary tale in the rise of power of the project/program manager relative to Microsoft? How might you prevent that in other companies?

The short answer is too many cooks. The long answer is, in the case of Microsoft and most successful companies, decay and bloat are inevitable. The story of PMs at MSFT is just part of that. You can't be lean and have 100,000 employees at the same time. Some roles don't increase in value as you add people, particularly meta-roles (e.g, leads, managers, etc.) Somewhere along the way the ratio of PMs to engineers got out of control, and as soon as PM types were in charge of controlling that ratio, it's not a surprise no corrections were made. Over a few years it becomes part of the culture, and all the developers expect PMs to be there to protect them or do the annoying work. It becomes symbiotic. In some cases, it's codependent, but not always. The basic rule I was taught, which has been forgotten, is make the tough choices. If you can't make decisive choices, you're lost. I bet if we asked most PMs at Microsoft (or managers at any large company) if there are too many PMs, they'd passionately agree. The problem and the solution is all right there.

At what point/time/team size/inflection point do you think a team needs a program manager?

Once you have more than a handful of developers, leadership activities emerge naturally or productivity drops. Who is the tiebreaker in tough arguments? Who figures out how everyone's work will fit together best for users? Who makes the best trade-offs among time, resources, and customers? Who has the clearest vision and articulates it the best? Who knows how to say NO? A program manager is an encapsulation of many of those intangible leadership and decision-making skills into one person.

According to Wikipedia, you have a goal to fill a shelf with books that you've written. First, what is the origin of this story? Also, how many books does it take to fill a shelf?

When I quit to try and be a writer, I needed a visible goal. Something I'd see all the time. A book is hard work, but in the grand scheme it's nothing: I want to die with a body of work, and having a long-term goal makes many short-term choices easier to make. I cleared the shelf closest to my desk and the only thing I'm allowed to put on it are books I've written (4). I haven't measured it as it's mostly empty, but I suspect I need to write 25 books to fill it. I believe I'm entirely capable of this challenge; it's purely a matter of priorities and I hope the empty shelf helps me prioritize my working life.

I'm always curious about a writer's process. Can you walk me through the process of how an idea turns into an article?

As a fun cheat answer, I made a time lapsed video of this process, with audio commentary. It's all there.

What is your perfect writing environment?

I'm not that picky - with the right music I can concentrate anywhere. I work mostly in my home office, but I can write in a coffee shop, too. If I'm working on a book I need more desk surface area for notepads, books and things.

What's the next book?

All I can say is it's something different :)

The romance surrounding disasters is history speaking. When the disaster shows up and you see it, no one but you knows that you want to throw up. That's your brain releasing a complex chemical cocktail that is physically and emotionally preparing you for the most sensible course of action - making a fucking run for it.

But, strangely, you do not run.

Having watched, participated in, and created a bevy of sky-falling situations in my career, I take the process I use for managing these situations for granted. It feels like I'm working on pure and spontaneous instinct, but these are honed instincts that I've built and refined over a great many DEFCON 1 disasters that I've had the unfortunate pleasure of attending.

This is my documentation of the process, and I sincerely hope you never have to deploy it, but I'm pretty sure you will. Before we start, a few assumptions and notes about this process:

• This is not a solo disaster. It's not just you, it involves a large group of people wrestling with a complex disaster , featuring different politics and motivations with an unknown root cause.
• No matter how much I sit here and EXPLAIN IN ALL CAPS THAT THIS PROCESS WORKS, you're going to skip at least one of the following four steps. That's cool. Each section includes a handy "This is what happens when you skip this section" addendum so you clearly understand the magnitude of your omission.
• I'm going to describe this process simply and serially, but in reality these steps overlap and often run in parallel.
• Oh yeah: there's a good chance this disaster is your fault.

Let's begin.

STEP NUMBER ONE: The Situation in the War Room

Your first job is to understand absolutely everything you need to know about the current state of the disaster - you are developing a mental model. Ideally, I want to be able to draw a complete picture for everyone about whatever the hell is currently happening. I need white boards - lots of them. I need a War Room.

The War Room is a base of operations. The requirements are simple: enough room to hold a quorum of people, a table, chairs, and lots and lots of white boards and markers. In this room, you are going to begin the immediate task of research, information gathering, and assessment. Every single person - everyone - who has any relevant knowledge about the situation is now going to parade through the War Room and you're going to capture and triangulate all of their knowledge.

The intent of the War Room is to break everyone from their flow. The War Room includes a menagerie of people coming in and out, empty pizza boxes and Red Bull cans, and white boards full of indecipherable scribbles. It sends a clear message: the status quo is not presently working.

As the people start streaming in for the inquisition, remember that this first step is data collection, not problem solving and not judgement. The hardest part of this step is not to jump when you think you see a place you can start moving. That! That! That! We need to fix that! It very well might be the right move to fix that, but you don't even know how much "that" there is, yet.

The initial goal during this step is information acquisition, not action. Each time you take action with incomplete data you risk stoking rather than extinguishing the disaster fire. And, by the way, this type of lack-of-foresight hyper-reactive mode is likely what got you here in the first place. The War Room is a place to focus on gathering a breadth of information first, then depth, so you can answer the question: "Do we understand the situation?"

For me understanding comes in three forms:

1. The picture I begin to draw repeatedly on the white board starts to represent a realistic picture of what has actually occurred.
2. A list of additional research, work, and potential next actions is developed, revised, and iteratively prioritized (but not yet acted on).
3. After much #1 and #2, I'm looking for a very precise moment. It always happens at a different time, but it is distinct. It is the moment I have the glimpse of a theory. This... is what we need to do.

What happens if you ignore this. A surprisingly number of smart people skip this step. They believe that they can both assess and solve the problem at the same time. This is akin to saying, "I will solve a math equation that I can only half see." It's absurd, but it's precisely what someone does when they start making critical decisions with incomplete data.

Action feels like progress, but undirected action is not progress, nor is it a plan. You're going to barge into the office and start barking orders because that is what everyone expects, but if your orders are not shaped by what you're really attempting to do, you are just scurrying people around aimlessly. Yes, you get lucky. Yes, everyone breathes a sigh of relief when you show up with your impressive sense of purpose, but in my experience when my direction doesn't map to intent, I'm usually getting no closer to propping up the sky.

STEP NUMBER TWO: The Bet Your Car Perspective

With your new found confidence that you've fully described the problem in front of you and have a semblance of a fix, my timely buzz kill is this: I am 100% absolutely certain that you've missed something essential in your first pass. There are two ways to discover this: you can jump straight into the next step and discover this absence at the most inconvenient and credibility-destroying moment, or you can check your math. To do this there are two phases:

#1 Vet your model with, at least, three qualified others. These are people who were not directly involved in Step #1 and who are people who don't need to understand the particulars of the disaster, but can appreciate the broad strokes because they've been there, and have no issue with telling you how screwed you are.

The joy that occurs at the end of Step Number One is the discovery of a fix. This moment of illumination is gratifying because it's the first time you believe there is a chance the sky can be propped up. Bad news: confidence is not a plan either. This situation is very common with software developers who are fixing bugs. They look at the bug description, write a few lines of code, rebuild, and, viola, it's fixed, because when they reproduce the exact steps of the bug, the bug no longer occurs. They have no idea that this small change in the import export code will also have unintended side effects on other file operations.

Having a solution where all the implications of the solution are not understood is not a fix. You must take the time explore all the implications, and in my experience this takes longer than it took to come up with your plan.

#2 Once your qualified others have discovered those gaping holes and unintended consequences that are guaranteed to exist in your fix -- your model -- you need to throw the current version on the nearest whiteboard in the War Room with the folks who are responsible for the work that's going to go down over the next few days and ask the same question: Does this picture, this list, make sense?

This is yet another error correction pass for gaping holes. It's also a pass on prioritization, but most importantly, it's an assignment of ownership.

One of the leading causes of sky falling situations is distributed ownership, and as a strategy distributed ownership seems very humane. We're going to put the right people on the right problems. We're going to empower the most qualified people to make their own decisions regarding their local problems because they have local knowledge and can make the best decisions using this knowledge. As a human being and a nerd who has an intense allergy to being told what to do, this model of distributed ownership appeals to me. I imagine small teams of bright people empowered because they feel they control their destiny.

A sky falling situation exists not because of a single failure on one team. It's a collection of multiple large and small mistakes on many teams that snowballs into an unexpected worse case scenario. Teams of people succeed and fail at scale. A likely major contribution to your current disaster is the fact that multiple well meaning and fully informed people looked at an emergent disaster and thought, "Well, someone who is not me is going to handle this, right?"

Since you're the person who is racing to work while panicking about the sky falling, I'm going to call you what we called these folks during my tenure at Apple: the Directly Responsible Individual or DRI. This name clearly describes the person who is directly responsible for whatever the situation might be and it's a person. It's not the Directly Responsible Group of People With Good Intentions Who Are Attempting to Feel Good by Building Consensus But Who Are Mostly Wasting Everyone's Time. It's an individual who is owning the entire situation.

However, as the DRI, the person who is most likely to be yelled at, your job is to be accountable. Your job is not to own all of the work, which is why the last part of this step is to put a proper name next to each and every task, and, as much as possible, this name should not be yours. When you're done with this assignment and someone in the War Room asks, "Hey, why isn't your name on the list?" Your answer is, "Because I'm the one making sure this whole thing is moving forward and I'm the one who gets fired if it doesn't."

What happens if you ignore this. There are a variety of skippable parts in Step Number Two, but I'm not worried that you don't have an initial plan or that you're incapable of pulling trusted others in to distribute the load. The part that has screwed me the most is failing to understand all of the implications of my theory.

A former boss used to put this into clear perspective, "Do you understand all of the implications of your plan?" Yes, I do. "Give me your car keys." Wait, what...? "Would you bet your car on the viability of your plan?" <sfx: shaking keys> Right, yeah, let me do one more pass.

STEP NUMBER THREE: Constant and Consistent Sky Propping Pressure

When the sky is falling, everybody is watching. Everybody wants status an hour ago. Everybody is talking to everybody else about the state of your sky-falling situation, which means the Grapevine is actively working against you. The amount of fear, uncertainty, doubt, and outright lies generated about what's actually going is impressive.

I'm assuming that you've got a credible plan that you've carefully vetted with others. I'm assuming you've assigned the work to competent folks who have a sense of ownership of their respective parts of the plan. I'm assuming the War Room is abuzz with the action defined by the plan. While all of this going on, your job is internal public relations.

As soon as I have something to report, I send the report to everyone who wants to know. If you walk by the War Room, poke your head in and ask, "What's up guys?" I add you to the distribution list. You're going to get every update until you beg to be removed. Anyone who mails me any random question -- they're on the list. The game here isn't just over-communication and Grapevine eradication, I'm still worried I missed something in the plan, and the status spamming is another another means of vetting both the plan and the progress.

How often do I send status? It's a judgement call based on progress relative to the beginning of the disaster. The better the legitimate progress, the fewer the updates. It moves slowly from hourly updates to daily updates and ultimately to weekly ones, which is when I start thinking about tearing down the the War Room.

What happens if you ignore this. It's hard to imagine someone not regularly broadcasting clear, demonstrative, measurable, and consistent progress. Maybe because you're still deep in research and don't yet have a theory and you don't want to call attention to that fact? Maybe there hasn't been significant progress on anything since your last update? You still send status. The message you send by consistently keeping the folks who care up to date is not: "We've made unique progress or we have a theory," the message is, "We are applying constant and consistent pressure on propping up the sky."

The Elusive Step Number Zero

I'm reading an early draft of this piece and it still feels like there's romanticism about this process. Look at me, Captain of the War Room, I'M GOING TO SAVE THE WORLD. There's nothing romantic about this situation. There's no glory in propping up the sky because, chances are, you and your team are partially responsible for this situation and depending on the severity of the disaster, there's a good chance you could get fired. Even if you fix it.

There's a fourth step to this process that I've confusingly labeled as Step Number Zero. I've put the first step last because I believe it's the most important part of this process. I've put the first step last because if you're able to confidently answer it, you'll greatly increase the chances that you won't repeat this disaster in the future. The question is: What, precisely, are you trying to do?

It seems like a dumb and obvious question at this very moment, but right now you're chilling with your iPad in the coffee shop. You've just taken your third sip of that half-caf quad-shot latte and you don't have a care in the world. If the sky was actually falling, you'd be racing to work, breaking speeding laws, and frantically thinking, How am I going to unfuck this situation?

Unfucking this situation is a sensible and obvious outcome, and while you're driving 105 miles an hour down Highway 280 to the scene of the crime, I will repeat myself: What, precisely, are you trying to do?

It's a hard question to effectively answer when people are yelling, but phenomenal answers sound like:

• We need to demonstrate to this customer that we are capable of exceeding their expectations.
• We need the people who depend on us to trust that their faith in us is not misplaced.
• We need the Planet Earth to understand that we aren't evil.

You will notice that none of these answers read "unfuck the situation". When the sky is falling, like I've said before, immediate action feels like precisely the right course of action because HELLO THE SKY IS FALLING. But there is a well defined reason for this situation, and it's likely you won't know the reason for a while. It's agonizing, but my advice is to not make any decisions on course of action until you have at least a credible answer to this question.

In the face of disaster, it's the wise person who does not act until they know. Unfucking the situation is a bandaid, understanding what you're truly trying to fix is a cure.

But you keep hearing this word. More importantly, you hear the urgency behind the word. You hear that choosing to design a thing is an important thing to do and the person saying it is also important, so you nod vigorously while silently thinking, "I have no fucking idea what you're talking about and I'm pretty sure neither do you."

There is no more evidence required that a magical focus on design can transform a company. In order for this to happen, engineering and design need to party more together, but there's a fundamental tension between design and engineering and understanding that tension is a good place to start thinking about design.

A Fundamental Tension

To understand the historic tension between the designer and the engineer, you need to go back to when software became mainstream, and in my mind that was with the arrival of the Internet. Software had been around and making piles of money long before Netscape, but it became a worldwide phenomenal when anyone, anywhere could mail anyone else a picture of their cat.

The arrival of everyone (and their cats) presented a challenge to these early software development teams. These teams were used to working with early adopters and their particular needs. See, early adopters are willing to put up with a lot of crap -- it's part of the deal we have with them. "You get to play with the latest and greatest, but it may explode at any point." Early adopters are cool with these explosions because early adoption makes them feel, well, cool.

When everyone arrived, everyone didn't want explosions -- they just wanted it to work. Engineers hear "just works" as "they want fewer explosions", but that's not what everyone wanted. They wanted to send a picture of their cat in the simplest way possible. They didn't care about JavaScript, security, frames or plugins; they just wanted to mail a picture of their goddamned cat without the application exploding.

Design results in the tangible translation between engineering thought: "fewer explosions" and user thought: "reliable, one-click cat photo mailing". Good design manages to both showcase the best of engineering efforts while simultaneously hiding them from the user.

After working with a wide of variety of designers, my opinion is that the role of design is:

1. Understanding what most users want.
2. Prioritizing and focusing on the most important of those wants.
3. Using this knowledge to exceed user expectations.

In the mid 90s, we, as traditional engineers, were not equipped for the role I described above. We'd been trained as builders of bits, and we believed that because we could build bits that we could build usable bits, but we were actually good at designing good product for ourselves... not everyone.

We don't see an explosion as a bad thing because we're intimately aware of how the sausage is made. We know that when a program crashes, you just re-launch the application and get back to work. Most humans on the planet do not see a crashed application this way. They are, at the very least, alarmed when something explodes. They're wondering, "Did permanent damage just occur?"

A Note to the Designer and the Engineer

With apologies to the incredible menagerie of design folk out there, this primer primarily focuses on the design denizens and design practices that surround software development. Furthermore, this primer is being written by an engineer for engineers. While I've spent a good many years soaking in design, I'm not a trained designer and the following descriptions of your history and your craft will piss you off with their simplicity, imprecision, incompleteness, and engineering bias.

But we're doing the same thing to design folk. We are well intentioned, but because we haven't repeatedly experienced the essential details, we are ignorant of them. We assume the act of describing the work somehow is equivalent to doing the work and, wow, are we wrong, but we are in good company because every eager master of their respective craft does this.

Engineers are uncomfortable with ignorance, but worse, we're bad at asking for help outside of our domain of expertise. This primer is the first step at building a solid bridge between our professions. So, chill. This is not a definitive design guide, it's a place for engineers to start thinking about design and if you happen to learn something about how we think -- super.

The Acronyms Matter

The phrase "we need a designer" is likely the first time you'll hear about design as a freshly minted software engineer. You wonder, "Well, what are they going to do that I'm not already doing?" The answer is an impressively long list of work that is beyond the scope of this article, but a good place to start is three key acronyms.

Like any profession, design is chock full of acronyms, but I'm going to focus on the three that are going be bandied about now that your boss has decided that design matters.

#1 GD -- Graphic Design

How they see the world:

Unfortunately, the most common name used to describe the graphic designer is, confusingly, the designer. The reasons are two-fold: first, he was the first person hired to work on the product who had any skill set outside of engineering, and second, he was placed in charge of the "the pretty". Someone in charge saw the first working prototype of the product and said, "This looks like an engineer threw it together", (you nod) and "We need a designer to fix this up" (blank stare).

You: "Fix what up?"

Person in charge: "I don't know... it just needs to... look prettier."

Designers who have not yet bolted from this article, yet, are now standing on their chairs screaming at the screen as they read this: "I KNOW THAT GUY."

Yeah, I know him, too. He's an idiot, but he has good intentions.

The craft of the graphic designer is a visual one. Via applications like Photoshop and Illustrator, a graphic designer gives visual form to ideas. Yes, the work they do is pretty, but it isn't just pretty. It speaks. It has an opinion about what it is and anyone who looks at it can see the opinion. Yes, a designer gives your application or website an air of clean, credible professionalism, but a well drawn anything does little to make your product easier to use.

A breakdown occurs when the person in charge walks into the graphic designer's office and says, "You're the designer -- can you help de-engineer the product?" Now, like you, the graphic designer wants to do more -- they want more responsibility -- so even though they don't know how the product works or who your users are, they sign up, thinking, "Sure, I'm a designer, right?"

And they produce. They generate an eye-pleasing prototype in Photoshop that you just want to lick. The graphic designer has done something most engineers cannot, and while important design work has occurred, the design is not remotely done -- your product simply has a pretty face. And while it does matter how your product looks, it's equally important how it works.

For the end of each section of this primer, I've selected a set of three design-related books that have shaped my design opinion. Let's start with design essentials:

• The Inmates Are Running the Asylum
• Meggs' History of Graphic Design
• Universal Principles of Design

#2 IxD -- Interaction Design

How IxD sees the world:

The interaction designer has a fascinating gig: they abstract function from form. Think of how you regularly navigate your favorite application. You follow a familiar path that we'll call a workflow: it's a series of mouse clicks and drags accompanied by your rapid-fire keyboard wizardry. This is your interface with the application.

The interaction designer's gig is the care and the feeding of the workflow. Via the deft usage of wireframes and flowcharts, the interaction designer defines and refines the step-by-step process by which a user can traverse the application.

These low fidelity descriptions of the functionality are confusing to those who don't understand their intent. Is this how the application is going to look? No, this is the interaction. These are rough approximations of the user interface intended to describe how it will work, not how it will look. But how is it going to look? Could we get drop shadows on that text? I love drop shadows and blue, I love words with a punch. Yeah, ok, right -- you need to leave now. The door is down the hall on the left and it's a lovely shade of blue.

The separation of function from form involves making a mental leap and there are those who believe one cannot be considered without the other. I believe the answer is somewhere in the middle. While I don't believe you need pixel-perfect comps in order to think strategically about interaction, I do believe working prototypes with sample interaction and animation is a far richer place to have a debate than a whiteboard.

A low-fidelity scribble can describe how your product works, and it does remove many of the subjective elements of design that are apt to derail a perfect good design conversation into a useless debate about drop shadows. But color, typography, spacing -- all of these elements contribute to the feel of your product, and how your product feels is equally important to how it works.

There are two other acronyms in close orbit to IxD that you're likely going to discover that are worth mentioning:

IA or Information Architect is a title falling out of favor in recent years. Perhaps the best model for thinking about IAs is the role of a librarian. The mindset of information architects is what gave us the Dewey Decimal System: a classification system for information. An IA does not sleep well until information has been organized. I haven't run into one of these folks in a while.

HCI or Human Computer Interaction is another title you'll discover. It appears this title is one granted exclusively from University and those sporting this title first self-declare their degree, then pause, then add their University. Yes, I have a PhD in HCI <pause> from Carnegie Mellon.

My experience with the HCI folk is that they are often brilliant researchers. If you want to understand every possible workflow your users are trying on your application, the elapsed time to complete these workflows, and the enumerated set of quantified emotional damage these workflows are inflicting on your users, find an HCI guy, give him 18 months, and you'll be <pause> dazzled.

Continuing with the reading list. These books were selected because I believe they are approachable by anyone. Reading these will not give you a complete design education, they will give you a good solid taste of the different parts of design:

• 100 Things Every Designer Needs to Know About People
• Envisioning Information
• About Face 3

#3 UXD -- User Experience Design

Finding the one image that describes how UxD thinks is tricky, so here are three (click on any for further detail):

User. Experience. Design. What do they care about? Well, you care about the whole damned thing. You care about the visual design; you care about the interaction design; but mostly what you care about is the experience of the user.

In my experience, the folks sporting the UxD title have nothing like a degree in UxD. It's a title they've adopted over the years because they know what I know: the title of designer is too general to be useful. Graphic designer and interaction designer are too specific. The user experience designer likely had an acronym in her past, but somewhere in the journey she decided it was to her advantage to care about the whole damned product.

Awesome.

There are a pile of design disciplines that contribute their acronyms and abilities to product design efforts and there is a time and place for each. The reason I seek the person that labels or thinks of herself as UxD is because I'm looking for a person who is willing to step up and be accountable for the entire experience.

The last part of the reading list includes absolute design classics. Yes, a book about comics:

• The Elements of Typographic Style
• The Design of Everyday Things
• Understanding Comics

Party. More. Together.

Usability as a design discipline is conspicuously missing from this list. Thing is, even if it had a clever acronym I wouldn't include it.

Prior to Steve Jobs' return to Apple, there was a decent centralized usability team equipped with those fancy rooms with one-way mirrors and video cameras. I'm certain these folks did significant work, but when Jobs returned, he shut it down and he cast the design teams to the wind. Each product team inherited part of the former usability team.

Now, I arrived after this reorganization occurred, so I don't know the actual reasoning, but I do know I never saw those usability labs used once and I would argue that in the past decade Apple has created some of the most usable products out there. My opinion is that the choice to spread the usability design function across the engineering team was intended to send a clear message: engineer and designer need to party more... together.

I can't imagine building a team responsible for consumer products where engineers and designers weren't constantly meddling in each other's business. Yes, they often argue from completely opposite sides of the brain. Yes, it is often a battle of art and science, but engineering and design want exactly the same thing. They want the intense satisfaction of knowing they successfully built something that matters.

A design-centered culture is at throwaway empty phrase unless everyone responsible for the culture of design is in each other's faces. Titles and acronyms give you a starting point for understanding what a person might do, but what really matters is the respect that comes when you take the time to understand how they build what they love.

Bored People Quit. From a traffic perspective, the clear winner for 2011. This is article is a good example of a piece where I've no idea how it will resonate until I hit the publish button. There are articles I feel have a good chance before they are published: they target a specific group and cover a topic I think will appeal to that demographic. This was not one of them.

The Rands Test. However, this was. This homage to The Joel Test is actually a collection of threads teased out from the entire archive. This gave the piece a chance to resonate. Finding the precise number of relevant questions and points was the tricky part of this piece. Yes, the math is fuzzy - it's actually quite hard to get 12 points.

You Are Underestimating the Future. Most articles stew in a Dropbox folder for weeks. This article was written in an hour, straight out of my head, the day Steve Jobs passed away.. Another notable: titles normally mutate a few times as a piece is being written and rewritten. This piece started and finished with exactly the same title.

Fred Hates It. Any time I get to disassemble a part of conventional business wisdom, I am content. Taking apart and rebuilding off-sites was payback for every off-site that wasted days of my time. I also liked the Fred character that was built around the piece. He was not central to early drafts, he just showed up -- yelling. I couldn't ignore him, so he got the title.

A Bag of Holding. Writing obsessive research-based articles about things you love feels like a guilty pleasure. As I wrote in the newsletter, these pieces seem to just get longer and longer and I briefly worry that I'll lose the audience. Reading the comments on the piece is a good reminder that obsession loves company.

Lastly, there are still charity shirts available. If you're reading this, there's a good chance you like reading, so why not share that love with someone less fortunate this holiday season.

I'm thankful for all of you who showed up in 2011 and wish you a spectacular 2012.

Happy Holidays.

Years of folding leather wallets with myriad pockets and flaps all yielded precisely the same result: a Costanza-sized monstrosity that contained random crap that at one time I thought I needed, but eventually became useless clutter. This collection sat in my back pocket as a constant reminder of a tidying task I never did. Meanwhile, the massive collection of clutter ultimately destroys the wallet because no wallet is designed to perpetually hold everything.

The current wallet is perfect.

It's perfect because:

1. There are zero moving parts. Whether it's a flap or a mechanical money clip, moving parts fail.
2. There is limited capacity. The card sleeve barely allows me to hold eight card-shaped objects. Eight. This means that each time I attempt to keep a receipt I think I'll need I have to fold it and slide it into the money clip. This means each time I handle my cash, I have to make a critical decision about the receipt -- do I still need it? You'd be surprised by the half-life of items in your back pocket that you recently thought were important when you're forced to look at them an hour later.
3. I'm not constantly stressing the architecture of the wallet attempting to contain everything. The current wallet has already lasted 4x as long as its predecessor.

It's with this wallet design win that I embarked on a quest for comparable bag.

The Bag Requirements

My requirements for a bag start with those of the wallet, but with an important essential addition: my bag has multiple use cases. My bag needs to adapt to whatever journey I'm currently on, whether it's a trip to work; a trip far, far away; or a trip where I'm sleeping in the dirt under the stars. A trip is either work or play, and since I work a lot more than I play, I chose to focus on work scenarios for my bag research.

I've heavily used two different types of bags over the past five years, and each has some win. To understand my initial requirements for a good bag, let's quickly look at each.

A Christmas present, this Johnson & Murphy messenger bag was the first work bag I loved. I find it gorgeous. A large, comfortable shoulder strap and decent space made this my go-to bag for years. All that was missing was the addition of a Incase sleeve to give my MacBook a little cushioning and I was set.

In the past few years I began to travel more, and the travel exposed a core weakness: the bag doesn't scale to far, far away. I found myself stuffing, shoving, and reorganizing headphones and power supplies in the bag, and while the magnet clasp works fine for a trip to work, when the bag is at capacity, it feels like it might pop open at any moment. I had a similar over the shoulder Tumi bag that was my workhorse for far, far away, but after sitting in a lot of airports, I'd seen a new development. Folks were wearing backpacks again.

I'm scarred by backpacks. My memory of backpacks was of these massive canvas-like bags full of immense and dense text books, crumbled paper, and a distinct smell of partially rotten peanut butter and jelly sandwiches. I remember constantly losing important papers in what was the seemingly infinite space contained within my bag, and I wasn't interested in returning to that frustration.

However, after countless hours watching travelers sport backpacks, it was time to get past my scarring and give backpacks another try. Tom Bihn's Smart Alec backpack was a chance to test this development.

After six months of steady use of my Bihn backpack, not only do I understand why people love them, I also better understand the complete set of questions and requirements I have for a good bag.

Does this bag make me look like a nerd? (Because I am.)

Bag religion is rampant. The only thing I'm looking forward to more than finishing this article is the crazy, foaming at the mouth bag nuts that are going to comment on this piece. My research is far less complete than in prior obsessive excursions, so bring it. I want to hear it. I've seen a lot of different bags, and my first requirement is that while I need my bag to be nerd-compliant, I don't want it to scream "nerd". This was part of my love affair with my messenger bag. It looked like I was part of the Pony Express when I was actually just a nerd hoofing my nerd crap hither and yon.

My bag needs to walk a delicate line between form and function. I need it to elegantly contain my various nerd crap, but I don't need to broadcast to the world that, yes, not only am I sporting my nerd gear, I also have a back-up of the aforementioned gear because I've built in redundancy. That's how I roll. I'm a nerd.

The messenger bag is a slight winner in this very subjective category. While the Smart Alec avoids most design disasters that remind me of JanSport-esque high school backpack monstrosities (straps, zippers, every kind of fabric everywhere, minimal pockets, and the color taupe), it makes less of a statement. It's slightly more function than form. However, it is a better answer to the question...

Am I going to beat you through the security line?

The hands down collective best measure for any bag is its relationship to your situation in the security line at the airport. Let's start with my mindset when I'm standing in line at security. I'm furious. Everyone's furious. While we suspect the security line is essential, as we stand in that endless line, we know -- we're absolutely sure -- there is a better way.

I'm fuming with this frustration when I finally get to the front of the line, but more importantly, I want to prove a point: I will now demonstrate to everyone the value of efficiency. Grab two trays, slip shoes off and put them in tray #1. Stuff wallet, iPhone, and boarding pass in shoes, belt off -- NEXT TRAY -- MacBook Air in second tray. Bag behind second tray, luggage behind that. And done. Why yes, I can do this and move the trays at the same time -- WHY CAN'T YOU?

No where in the above process did you see "futzing with my bag and looking for shit". In times of stress, a good bag demonstrates a couple of essential design points:

• Easy access to the items I commonly need. This means my computer is a single zipper away, but this ease of access does not mean the safety of these essentials is compromised. The Smart Alec is a clear winner here. In addition to the main compartment, there are two external side pockets that are large enough to hold the answers to most travel questions.
• Simply amazing zippers. My messenger bag has a magnet clasp and that works, but when I'm moving quickly, I'm wondering when this bag held together with a magnet is going to explode. When I close any pocket on my bag, I want to be left with the clear impression that the pocket is seriously closed.
• A minimum of crap hanging from the bag. Each strap is an opportunity to snag myself on a random piece of crap that I didn't happen to see at the least opportune time. Traditional backpacks are the worst offenders when it comes to these straps. The designers seem to think I'm always mere seconds away from base jumping off a bridge where I need my backpack affixed to me in seven different ways. I don't. I need two straps. That's it.

However, I do want to know...

Can I go ninja?

The rule is: the further you are from your cave, there's the exponential increase in the chance something will go wrong at the least opportune time. The best example of this is standing in front of 1,000 people who are expecting you to smoothly and expertly talk for the next hour and you've just discovered your MacBook doesn't connect to the venue's projector.

In my bag, I'm certain I have video connectors for most projectors on the planet. Furthermore, I have a universal power converter, a power supply, two presentation remotes, and sundry other essential white cables. All of these items are expertly collected in what Tom Bihn calls a Snake Charmer bag. This mesh bag is not only of a size that it can handle all of these items, it takes oddly shaped items such as power supplies and Jamboxes and molds them into an easily transportable rectangle that fits inside of my bag.

To allow for ninja-like moves, a good bag is designed to maintain state, which means:

1. There is a knowable set of intelligently aligned pockets of a size and shape that make sense. This is where my messenger bag fails. In order to maintain that Pony Express feel, the messenger bag design assumes that everything I'm going to lug about is roughly shaped like a stack of 8.5x11 paper. While the MacBook and the iPad are paper-shaped, I have essential items that aren't square: delicate sunglasses, clumps of pens, and bizarrely shaped collapsible headphones. When I attempt to gear up for the long trip, it's clear from the resulting lumpiness that the messenger bag was designed for a pleasing form and not useful function.

   The Smart Alec backpack not only has a sensible number of pockets, they are of a size that accounts for the fact that oddly shaped items follow me on my travels. More importantly...

2. In time of stress, the items are readily accessible, remain safe, and don't shift around. I can't predict when I need to go ninja. I don't know when it's absolutely essential that I have a pen ready to go in five seconds. When this moment does arrive, I don't want to be digging feverishly around my bag, placing various items on the floor as I search the bottom of the bag where the small stuff has fallen. The Smart Alec backpack not only has a sensible number of pockets, they are readily accessible and not cavernous. At this moment I can tell you: right side external pocket is notebooks and the essential small crap bag (which I'll explain in a moment), left external pocket is pens, mints, and playing cards, and the internal top pocket is safe and easily accessible for sunglasses, random small pieces of paper, a passport, and the occasional stash of hard candy.

All my stuff, readily accessibly at a moment's notice -- that's pretty ninja. Still...

Is my bag smarter than I am?

Everything is exponentially and unnecessarily harder when you're stressed, and it's in these moments that you appreciate the design of a good bag. A well-maintained state allows me to go ninja, but knowing precisely where my stuff is safely located is just the first step. A well-designed bag is thinking for you when the last thing you're doing is thinking. Some examples:

• Sub-bags. In addition to intelligent pocket size and positioning, Bihn pushes an idea to help me maintain state: sub-bags. For everyday trips, I have a single sub-bag that I'll call "essential small crap". Everything I'd normally lose or constantly be untangling is in a small bag that is transparent on one side, and which sits well contained precisely in the same pocket.
• An unexpected sense of space. This is a direct contradiction to my requirement that my bag prevents me from randomly collecting crap, but part of being ninja is the need to scale. I will randomly need to lug around a randomly shaped something from here to there and my preference is that my bag does this without fuss. The messenger bag fails here, especially on longer trips. I'm at max capacity on a long trip, which means I'm shoving newly acquired items in coat pockets or onto fellow travelers. As for the Smart Alec bag, I never felt I've filled it. Sure, I can lug your randomly shaped something... anywhere.
• Agility. My agility test is relatively simple: how many people are impacted/aware when I attempt to retrieve my MacBook while sitting in the middle seat? Any answer higher than one is too many. For the messenger bag, I first need to find the handle, which, given how it was shoved under the seat in front of me, is trickier than it needs to be. Then, I slide the bag out, lift the flap, unzip the Incase, and slide out the hardware. If you're sitting on either side of me, you're going to be well aware of this process because of my odd elbow gyrations.

  The backpack is shaped like a bullet. You slide the base easily under the seat in front of you, leaving the tip pointed directly at your feet. When I need something, the handle is at the tip of my toes, the zipper is easy to grab and works every time, and the Brain Cell holding the MacBook is right there. If you're sitting next to me you'll end up wondering, "When did he pull his computer out?" Whether it's shoved into an overhead compartment, slid under a seat, or thrown in the back of a taxi, my bag needs to remain accessible and useful. This means I can get to it, and once I get to it, I can perform whatever action I intend without annoying every single person around me.

• Full range of motion. The defining aspects of a backpack are its most obvious -- it's on your back. After many years of single-strap messenger bags, I was shocked when I moved to the backpack and suddenly had two hands. A messenger bag does not full occupy one of your arms, but your shoulder is in a constant balancing dance with the bag to make sure it's in the right place. With a backpack, this is a non-issue. When it's on your back it's gone and you've got a full range of two-handed ninja motion.

Through its design, a good bag makes me look smarter by giving me deft answers to most travel disasters, but I have one more request.

Can I take a bullet? Do I look good after I've taken a bullet?

As my bag accompanies me everywhere on the Planet Earth, it's apt to encounter small random disasters. Briefly dragged on the asphalt, being drenched by half a cup of airplane coffee, or being unceremoniously thrown in the back of a cab. When these micro-disasters are going down, I need two things of my bag:

1. Everything in it needs to admirably survive and generally remain in the same location, and,
2. The disaster results in the bag acquiring additional character.

Sturdy is the word you're thinking. Good solid craftsmanship. Yes, this is all true, but the art lies in building a bag that doesn't look tired after the unexpected has occurred -- the bag needs to look like it's lived.

The messenger bag is a solid winner here. The bag has had the shit kicked out it, but it doesn't look like it's beaten, it looks worldly. The Bihn bag is well constructed out of impressive sounding materials such as ballistic nylon. It looks sturdy, it looks like it can take a bullet, but once the damage is done, I don't know what story the damage will tell.

Efficient Disaster Management

When I stand up to go somewhere, the routine is precise. Right pocket, wallet. Left pocket, iPhone. Keys in hand, grab my bag and go. It's this sort of workflow precision that allows me to stay cool when the unexpected occurs. My inner dialog during the situation is, Well, see, I've got my shit together, so even though this unpredictable thing is going down, I'm doing my part to support predictability.

Whether it's a wallet or a bag, its design needs to encourage and support my irrational worldview that with the proper level of organization those disasters, large and small, are all manageable.

However, this free tech support does come at a cost. I have a system for evaluating a problem which is accompanied by colorful inner monologue. The following flowchart explains both the details of how I triage a problem, how I might fix it, and how and why I'm likely to swear while I'm helping.

Download the larger version.

1. It's awesome.
2. It sucks.
3. Apathy."

This short list of responses captured me with their lack of subtlety. Three bullets effectively describe the majority of opinions people have about topics that often deserve more consideration. While Robert's eventual point was different, his observation serves as a starting point for understanding why I'm once again offering a t-shirt supporting a literacy charity.

As with all other prior shirts, all of the profits go to First Book, a charity focused on promoting children's literacy. The reason I continue to choose this charity is simple: I think the more people take the time to read increases the likelihood that they can build a defensible opinion.

Having a defensible opinion takes work. There is infinite information out there and that means you need to pick and choose the topics where you want to stop and ask, "Wait... why?" I'll explain via a creepy story.

Back before there was a publicly available Internet, a doctor told my mother that smoking would keep the baby's birth weight down. Funny thing is, it's true. The unfunny thing is that low birth weight babies are at an increased risk for serious health problems and lasting disabilities. The decidedly unfunny thing remains -- it was her doctor who told my mother this "good news".

History is full of lies and ignorance propagated by people who've put their trust in the ideals of allegedly qualified others. Now, as we live in a world divided by opinions acquired via Twitter, it's never been easier grab onto a clever 140-character quip and assume it's the truth. The fires of ignorance burn wildly on these acts of intellectual laziness.

Having an opinion takes work. It means stopping in your tracks and staring conventional wisdom in the face and asking it to explain itself. It means drilling deeper than the conventionally polarizing opinions that a topic is simply awesome, it totally sucks, or it's completely irrelevant to you. Chances are, it's a little bit of all three, but that type of ambiguity is mentally exhausting, right? Can't we just love or hate? It's so much easier to yell when it's right versus wrong or us versus them.

Having an opinion means starting to explore in Wikipedia as a means of defining and refining your curiosity, but not trusting that it's true. It means researching and building an intellectual map around a question. It means having the confidence and the courage to open a book, find the facts, and working to build a complex and defensible opinion so you can personally answer the question: "Why?"

And I think it's a habit we want to encourage as early as possible.

The third version of the Rands charity shirt has a new purchase option. You can either purchase the lovely red shirt or the limited edition gun metal version, which also includes a set of customized Field Notes. The clingy bamboo stylings of previous shirts are gone and replaced with American Apparel's finest short-sleeve cotton t-shirt. Again, all proceeds of both shirts go to First Book.

I'd like to thank Robert Padbury and Jim Coudal for their generous donations to this effort. They are both awesome and now you know why.

"I'm screwed." I have not yet begun the presentation, but I'm imminently starting. This phase sucks. Every possible screw-up I've ever performed or could perform is running through my mind and my gut instinct is a sensible "just fucking run for it". This state does not end when I walk up on stage and begin talking. In fact, this phase doesn't end until...

"I'm really just glad that I don't appeared to be screwed." After a few minutes, after I've stepped through the introductory slides, gotten the audience to laugh once, and have a sense of the room, I pass into the second state, which is a presentation steady state. I'm still operating at very high nervous energy because I'm a nerd introvert standing in front of a room full of strangers, but I've had enough success that I believe I can make this presentation happen. My practice has paid off and this is the state I operate in until...

"The end." After all of the build-up of all potential screw-ups, plus my very high energy, and the multiple sleepless nights that led into this presentation, this final state used to show up with a calming sense of relief: "Whew, I'm like three slides away from escaping the firing squad. Didn't think I'd make it without taking a header off the back of the stage." I take a deep breath and then race towards the ending, and when I get there, I blast by it and stand there lamely wondering why everyone isn't clapping. The room is full of exactly four seconds of dead air. What happened?

Either the audience did not know I was at the end, or maybe they had no idea what I just said, or worse, they had no idea what was important.

The End of the Beginning

The sister studied communications in college, and one break she returned full of interesting points about the construction of movies. A point that stuck: a movie has a well-defined point when the beginning is over. The main character has been introduced, the dramatic premise has been established, the dramatic situation around the premise has been constructed, and with a single defining action, the scene changes, and you're done with the beginning.

Try it. Next time you're watching a movie, watch for when the beginning has ended. Be warned, once you start, it's hard to stop. It's been years since I learned about the endings of beginnings and I still compulsively measure for when the beginning has ended.

We spend a lot of time worrying about the importance of beginnings: first impressions, great opening lines, or the perfect handshake. The theory is that a huge amount of context regarding a person, place, situation, or thing just shows up in the first few seconds of interaction. I buy that because people like to believe they understand what is going on long before they do, and with experience, sometimes they actually do.

A good beginning grabs your attention. The great opener elegantly and simply explains why you should listen. The well-played handshake instantly physically connects you to a person. Any of these beginnings, well executed, focuses you on the task ahead of you and asks you to listen, but what have you actually learned? Nothing. All a good beginning does is open you up to possibility.

The bulk of learning comes in the middle of the story and there's a lot to be said for great middles. The middle is the bulk of the plot of your life, it's the meat of the conversation, and it explains the intent described by the beginning, but I don't think middles are easy to screw up. I think we're inclined to explain our agenda, but I think we're undervaluing the power of the ending.

Awkward Endings

You sit down for coffee at Philz with a co-worker. Your go-to beginning with co-workers is something lame and innocuous like, "How was the weekend?" It's a verbal handshake of a question intended to create a sense of familiarity. You have an agenda, he has an agenda, so you spend the middle wrangling through your agendas, making decisions, creating next steps.

Then, when the agendas are all done, there's a pause where each of you is clear that you're somewhere near the ending. Like the way I used to close a presentation, I finish these types of meetings with a hurried declaration of "cool". But inside of that "cool" I'm making some massive and incorrect assumptions, including:

• The idea that every single thing important to me is at the front of your mind.
• Every action we've agreed upon is clearly assigned and ready to go.
• Everything that was a professional issue that arose between us during this time (unless otherwise flagged) is fully resolved.

"Cool" covers none of this. "Cool" is just another crap ending.

A good ending, whether it's a meeting, a presentation, or an article:

• Introduces itself, invites the audiences to the stage, and acknowledges receipt.
• Reminds everyone what was actually important.
• Says one more thing.

An introduction, an invitation, an acknowledgement. Whether you're filming a movie, running a meeting, or writing a presentation, each is a story with a beginning, middle, and end. The first responsibility of the end is to remind everyone involved what parts of the story we're supposed to care about and you need to tell them when the ending has begun.

The introduction of the ending varies depending on the medium. In a presentation, I stop before my ending and count five alligators and pace. In those alligators, the audience wonders, however briefly, "Did he forget where he was? Did he lock up?" I didn't. I just wanted your attention before I told, "Everything important that just happened is about to happen again. Quickly."

With their attention in hand, you need to change perspective. What was the point of this speech, meeting, or article was yours -- now it needs to be theirs. A good ending is a selfless act where you put everything important squarely in the audience's lap. Whatever your point was, it's now their point, their lesson, their view of the story. The invitation is a question: "How can I make this theirs?"

Do you have a friend who sucks at goodbyes? You stand up, walk to the front of the bar, shake hands, and they walk off. You stand there with a strange emptiness, wondering, "Did anything we just talk about actually matter?" Of course it did. You've known them for years and they listen hard and they debate hard, so what happened? They suck at goodbyes, at endings. The last part of an ending is deceptively simple; it's the audience acknowledging, "Yes, we heard you". They clap (or they don't), they repeat the most important part, or they sit there, tilting their heads slightly to the left with a half-grin, and psychically project: "Yes, I understood what you just said." The act acknowledges receipt of the ending and you've got to ask for it.

A reminder. As I write, I find myself staring at the beginning of a lot of endings. I'm clearly at the ending because the last thing I said was the last thing I wanted to say and I'm now staring at nothing. The easiest trick in the book regarding the absence of an ending is to look at your beginning. It's likely been long enough for both you and your audience that a quick repeat of the beginning is just the thing to starting an ending, but it's just a start. You said some important things in the middle, too. How about synthesis of that, too? Yeah, that's looking good.

Ok, throw it away.

A pure repeat of the high points of the beginning and the middle is a total cop-out. You need to find a different way to say the same thing. It's a different story, a slightly different perspective. Sure, you can use the same pictures or bullet points, but the words that you use need to be different. What you really need is...

One more thing. The beauty of a good ending is that you can't find it until you've written, spoken, or built a good part of your beginning and middle. For me, that's the high in building a thing -- the moment of clarity when you're hopelessly lost somewhere in the middle and you suddenly discover the slide, the paragraph, or the design that immediately and simply encompasses everything you've just been trying to say. You need to save that discovery for the end.

Endings Everywhere

The ending compliments the size and type of story. If you're drunk with Paul in the bar, the ending is small and it's social. I'm shaking his hand... with both hands because we talked about some shit and while I won't remember any of it, I want us both to remember that we did. The email ending is written and deliberate. If I sign this 'Sincerely', I will obliterate everything important I just wrote. So, I will choose "In related news, you rule..." The meeting ending is more formal. The action items aren't world changing, but your ending, the reminder that we actually love working here, explains to everyone that there is no crap work when you're doing what you love.

If your ending feels empty, perhaps you haven't said anything. Perhaps you have no story to tell or perhaps you don't what what that story is, yet. If your ending is full, if your ending is an invitation to remember what's clearly important, and if your ending leaves them with just a little extra, you've succeeded, it's a story told.

One more thing. Remember, they never remember the beginning. They only remember how it ended.

It's a test with 12 points and as Joel says, "A score of 12 is perfect, 11 is tolerable, but a 10 or lower and you've got serious problems". More important than the points, his test clearly documents what I consider to be healthy aspects of an engineering team, but there are other points to be made. So it is completely an homage to Joel that I offer The Rands Test.

I was employee #20 at the first start-up and the first engineering lead. Over the course of two years, the team and the company exploded to close to 200 employees. This is when I discovered that growing rapidly teaches you one thing well: how communication continually finds new and interesting ways to break down. The core issue being the folks who've been around longer who also tend to have more responsibility. As far as they're concerned, the ways they organically communicated before will remain as efficient and simple each time the group doubles in size.

They don't. A growing group needs to continually invest in new ways to figure out what it is collectively thinking so anyone anywhere can answer the question: "What the hell is going on?" This is the first question The Rands Test answers. As I'll explain shortly, the second question The Rands Test helps you answer is selfish. The second asks: "Where am I?"

12 Points

Let's start with bare bones versions of the questions and then I'll explain each one.

• Do you have a 1:1?
• Do you have a team meeting?
• Do you have status reports?
• Can you say No to your boss?
• Can you explain the strategy of the company to a stranger?
• Can you explain the current state of business?
• Does the guy/gal in charge regularly stand up in front of everyone and tell you what he/she is thinking? Are you buying it?
• Do you know what you want to do next? Does your boss?
• Do you have time to be strategic?
• Are you actively killing the Grapevine?

(Note: While I'll explain each point from the perspective of a leader or manager, these questions and their explanations apply equally to individuals.)

Do you have a consistent 1:1 where you talk about topics other than status? (+1)

I think you'd be hard pressed to find anyone who would suggest 1:1s are a bad idea, but the 1:1 is usually the first meeting that gets rescheduled when it hits the fan. I'm of the opinion that when it hits the fan, the last thing you want to do is reschedule 1:1 time with the folks who are likely either responsible for it hitting the fan and/or are the most qualified to figure out how to prevent future fan hittage.

Furthermore, as I wrote about in The Update, The Vent, and The Disaster, conveyance of status is not the point of a 1:1; the point is to have a conversation about something of substance. Status can be an introduction, status can frame the conversation, but status is not the point. A healthy 1:1 needs to be strategic, not a rehashing of tactics and status that can easily be found elsewhere.

A 1:1 is a weekly investment in the individuals that make up your team. If you're irregularly doing 1:1s or not making them valuable conversations, all you're doing is reinforcing the myth that managers are out of touch.

Do you have a consistent team meeting? (+1)

The team meeting has all the requirements of the 1:1 -- consistency and a focus on topics of substance -- but don't give yourself a point just yet.

Status does have a bigger role in a team meeting. As we'll talk about shortly, the Grapevine is a powerful beast and a team meeting is a chance to kill it. I have a standing agenda item for all team meetings that reads "gossip, rumors, and lies" and when we hit that agenda item, it's a chance for everyone on the team to figure out what is the truth and what is a lie.

After that's done, my next measure of a team meeting is: did we make tangible progress on something? I don't know what you build, so I don't know what's broken on your team, but I do know that something is broken and a team meeting is a great place to not only identify the brokenness, but also to start to discuss how to fix it.

If you're killing lies and fixing what's broken in a team meeting, give yourself a point.

Are handwritten status reports delivered weekly via email? (-1)

If so, you lose a point. This checklist is partly about evaluating how information moves around the company and this item is the second one that can actually remove points from your score. Why do I hate status so much? I don't hate status; I hate status reports.

My belief is that email-based status reports are one of the clearest and best signs of managerial incompetence and laziness. There are always compelling reasons why you need to generate these weekly emails. We're big enough that we need to cross-pollinate. It's just 15 minutes of your time.

Bullshit. The presence of rigid, email-based status reports comes down to control, a lack of imagination, and a lack of trust in the organization.

I want you to count the number of collaboration tools you use on a daily basis to do your job -- not including email. If you're a software engineer, I'm guessing it's a combination of version control, bug tracking, wikis, CRM, and/or project management software. All of these tools already automatically generate a significant amount of status regarding what has tactically gone down each week.

When someone asks for a status report, my first thought is: "I'm already generating piles of status on these various tools, why not just ask those?"

Well, there's a lot of noise in those tools. Well, write a report that takes out the noise -- collaboration tools are built around reporting. The status information is out there. In what managerial textbook does it say it's a good idea to "Distribute the task of figuring out what is going on to the people who are performing the work?" That's, like, your job.

Well, what I really want is your high level assessment of the week. Three things that are working, three things that aren't, and what we're going to do about it. Ok, now we're talking. I can do a strategic assessment of the week, but why don't we just put that at the beginning of the 1:1? That way when you have questions (and you will), we can have a big fat debate.

But I'd like to have a record I can review later. Super, feel free to write down anything we talk about.

Yes, status reports are a hot button for me. I've written hundreds of them and each time I've begun one, I start by thinking, "Why in the world do I feel like I'm performing an unnecessary act?" Status reports usually show up because a distant executive feels out of touch with part of his or her organization and they believe getting everyone to efficiently document their week is going to help. It doesn't. Emailed status reports say one thing to 90% of the people who wrote them: "You don't value my time". This leads us to our next point...

Are you comfortable saying NO to your boss? (+1)

Perhaps a better way to phrase this point is: do you feel your 1:1 with your boss is somehow different than every other meeting you have during the week? Part of healthy communication structure is when information moves easily around the team, organization, and company, and if you walk into a meeting with your boss always on your best behavior and unwilling to speak your mind I say something is broken.

Yes, he or she is your boss and that means they write your annual review and can affect the trajectory of your career, but when they open their mouth and say something truly and legitimately stupid, your contractual obligation as a shareholder of the company is to raise your hand and say, "That's stupid. Here's why..."

Easier said than done, Rands.

Ok, don't say it's stupid.

Here's the deal. I believe that leaders who think they're infallible slowly go insane with power created by the lie that being wrong is a sign of weakness. I screw up -- likely regularly -- and I've been doing various forms of this gig for twenty years. While it still stings when I stumble upon or others point out my screw-ups, I'd sooner I admit I fucked up, because then I can figure out what I really did wrong faster, and that starts with someone saying "No".

Can you explain the strategy of your company to a stranger? (+1)

Moving away from communications, this point is about strategy and context. If I was to walk up to you in a bar and ask what your company did, could you easily and clearly explain the strategy?

This is the first point that demonstrates whether you have a clear map of the company in your head, and you might be underestimating the value of this map. If you're a leadership type, chances are you can draw this map easily. If you're an individual, you might think this map is someone else's responsibility and you'd be partially correct: it is someone else's job to define the map, but it's entirely your responsibility to understand it so you can measure it.

As we'll see with the following questions, The Rands Test isn't just about understanding communications, it's about understanding context and strategy. How do you think the employees of HP and Netflix feel given the strategy flip-flops over the past few months? Safe or suspicious? Let's keep going...

Can you tell me with some accuracy the state of the business? (Or could you go to someone / somewhere and figure it out right now?) (+1)

It's a brutal exaggeration, but I think you should independently judge your company the same way that Wall Street does: your company is either growing or dying. Have you ever watched the stock price of a publicly traded company the day after they announce that they are going to miss their earnings numbers? More often than not, no matter what spin the executives have, the stock is hammered. It's irrational, but what I infer when I see this happen is that Wall Street believes the company has begun a death cycle. If the executives can't successfully predict the state of their business, something is wrong.

I realize this isn't fair and there are myriad factors that contribute to the health of the business every single day, and I encourage you to research and understand as many of those as possible. But when you're done, I'd also like you to have a defensible opinion regarding the state of the business, or at least a set of others whose opinion you trust.

This is a picture that you are constantly building, and this is an easier task if you've given yourself a point on the prior question regarding company strategy. If you have a map of what the company intends to do, it's easier to understand whether or not it's doing it. This leads us to...

Is there a regular meeting where the guy/gal in charge gets up in front of everyone and tells you what he/she is thinking? (+1) And are you buying it? (+1)

Our last point regarding context involves the person in charge. In rapidly growing teams and companies there's a lot going on -- every single day. When the team was small, the distribution of information was easy and low cost because everyone was within shouting distance. At size, this communication becomes more costly at the edges. Directors, leads, and managers -- these folks tend to stay close to current events because it's increasingly their job, but it's also their job to take steps to keep the information flowing, and it starts with the CEO.

On a regular basis, does your CEO stand up and give you his impressions of what the hell is going on? Whether it's 10 or 10,000 of you, this is an essential meeting that:

• Gives everyone access to the CEO.
• Allows him/her to explain their vision for the company.
• Hopefully allows anyone to stand up and ask a question.

If the value of this meeting isn't immediately obvious to you, I'd suggest that you are one of those lucky people who already has a good map of the company as well as a sense of the state of the business. That's awesome -- here's a bonus point for you: does the CEO's version of the truth match yours or is he/she in a high Earth orbit with little clue what is actually going on? Give yourself a point if it's the former and if it's the latter, what does that say about the state of the business? Growing or dying?

Can you explain your career trajectory? (+1) [Bonus: Can your boss? (+1)]

Next, switching gears a bit, give yourself a point if you -- right this very moment -- can tell me your next move. You're already doing something, so explain what you're going to do next. It's a simple statement, not a grand plan. One day, I'd like to lead a team.

Part of a healthy organization isn't just that information is freely moving around; it's what the folks receiving and retransmitting it are doing with it. You're going to mentally file and ignore a majority of this information, but every so often a piece of information will come up in a 1:1, a meeting, or a random hallway conversation, and it will be strategically immediately useful for you to know what you want to do next.

• Angela got a promotion and her team is great and I've always wanted to be a manager.
• Jan just opened a requisition and his group is working on technology I need to learn.
• They fired Frank. That creates a very interesting power vacuum...

You can argue that even without a plan you'd make the same opportunistic leap, but I've found that having a map is usually a better way of getting to a destination.

There's a bonus point here as well. Does your boss know what you want to do next? He or she likely has even more access to the information moving around the company, and whether they like it or not, have equal responsibility to figure out how to get you from here to there.

Do you have well-defined and protected time to be strategic? (+1)

If you gave yourself two points on the prior question, congratulations, I think you're in better shape than most, but there's one more point. Are you making progress towards this goal? Can you point to time on your calendar or even just in your head where you are growing towards your goal?

I like being busy. Like really busy. Like getting in, grabbing a cup of coffee, and suddenly finding the coffee is cold, it's 6pm, and I forgot to eat busy. Busy feels great, but busy is usually tactical and not strategic. This is why I'm constantly maintaining my Trickle List -- it's my daily reminder of doing work that is larger than right now.

If you have time where you're investing in yourself while you're at work and your boss is cool with it -- give yourself a point.

Are you actively killing the Grapevine? (+1)

When Grace walks in your office, you know she knows something by the look on her face. She moves to the corner of the office and starts with, "Did you hear...?" and the story continues. It's a doozy, full of corporate and political intrigue, resulting in your inevitable response: "No. Way."

Being part of a secret feels powerful. In a moment the organization reveals a previously hidden part of itself, and in that moment you feel you can see more of the game board. So, that's why they fired him. I was wondering. Grace finishes with the familiar, "Don't tell anyone," which is ironic since that's precisely what was asked of her 15 minutes ago.

There is absolutely no way you're going to prevent folks from randomly talking to each other about every bright and shiny thing that's going on in your company. In fact, you want to encourage it. 1:1s and meetings are only going to get you so far. The thing you can change is the quality of the information that's wandering the company.

In the absence of information, people make shit up. Worse, if they at all feel threatened they make shit up that amplifies their worst fears. This is where those absolutely crazy rumors come from. See, Kristof is worried about losing his job so he's making up crazy conspiracy theories that explain why THE MAN IS OUT TO GET HIM.

Without active prevention, the Grapevine can be stronger than any individual. While you can't kill the Grapevine, you can dubiously stare at it when it shows up on your doorstep and simply ask the person delivering it, "Do you actually believe this nonsense? Do you believe the person who fed you this trash?" Rumors hate to justify themselves, so give yourself a point if you make it a point to kill gossip.

Magnitude and Direction

There is a higher order goal at the intersection of the two questions The Rands Test intends to answer: Where am I? and What the hell is going on? While understanding the answers to these questions will give you a good idea about the communication health of your company, the higher order goal is selfish. I'll explain.

I think of the two lines of questions as a vector. A simple vector can be drawn as two points connected by an arrow, but a vector is far more interesting. It's a geometric object that describes both direction and magnitude. Understanding how information moves, how you communicate with your boss, and being able to describe both your career strategy and that of your company sketches a vector in your head. The first point is you at this very moment and the other point is where you want to be. The distance and direction between the two start to explain how you're going to get there. I love vectors because they draw a picture about a complex problem and I hope as you were answering the questions above this mental picture began to appear in your head.

Like the Joel Test, the point of the Rands Test is not the absolute score, but the score is good directional information. If you got a 12, I'd say you're in a rare group of people who have a clear picture of their company and where they fit in. Between 8 and 10, you are likely troublingly deficient in either communications, strategy, or your development - it depends where the points are missing. Less than 8 and I think you've got a couple of problems.

There are a lot of different scenarios I expect folks to find themselves in as they explore these questions, which is why it's tricky to proscribe specific action. Your company may be doing well, but you may be unhappy and have no clue what you want to do next. You might love your job, but have no idea whether the company is actually growing. Your course is dependent on what you care about and the Rands Test points out good places to start.