• home
• tech life
• management
• vegas
• glossary
• archives
• about

How to Run a Meeting

I bag on meetings.

I bag on meetings because like any nerd I expect the universe to be efficient and orderly and there is no more vile a violation of this sense of orderliness than a room full of people randomly bumping into shit and calling it a meeting.

There are solid meetings out there. There are meetings that build a sense of structure, move forward for the entire hour, and finish with a sense of accomplishment. The question is: how do we make sure every meeting is like this? Let’s start by understanding why meetings showed up in the first place.

You’re sitting in your office eating a sour apple salt water taffy and you’re fully in the Zone. It’s great, forgetting there are other humans on the planet Earth; it’s blissfully productive until Richard walks in the room and Richard Wants To Talk.

“Stan is one day away from totally screwing our performance…”

Maybe if I ignore him, he’ll go away.

“No one is code reviewing his stuff…”

Maybe if I offer him a sour apple salt water taffy he’ll go away.

“And he just checked into your component.”

“He what the fuck what? STAN!”

Now, an important transition is occurring as you and Richard are running down the hallway to grab Stan. When Richard was rambling in your office, the two of you were talking, and talking is a conversation. Anything goes when it comes to a conversation. It’s a simple negotiation: make a point, get a response, retort, retort back. A conversation is verbal ping pong: there are many different styles, but for two players, you bat the little white verbal ball back and forth until someone wins.

When you and Richard walk into Stan’s office, the conversation has now become a meeting, and the core difference between a conversation and a meeting is that it needs rules so people know when to talk.

Alignment versus Creative

As I’ve mentioned before, there are two useful types of meetings: alignment and creation. Briefly, alignment meetings are tactical communication exchanges that rarely dive into the strategic. These are fine meetings that have a weekly cadence, and while there are lots of ways to screw up these meetings, their tactical repetition often keeps them on the rails.

Creation meetings — diving into solving a hard problem — involve, well, more creativity. Each hard problem requires a unique solution, and finding that solution is where creation meetings can go bad.

I’ve documented many of the rules for meetings in other articles. In this piece, I want to talk about some of the obvious and non-obvious rules around meetings.

A meeting has two critical components: an agenda and a referee. Let’s start with the obvious — the agenda. The agenda answers the question everyone is wondering as they sit down: how do I get out of this meeting so I can actually work?

Different referees have different agenda moves varying from sending it out in email before the meeting to writing it down on the whiteboard at the beginning of the meeting. Whatever the move, the agenda exists in everyone’s head - everyone can answer the question, “What do we need to do get the hell out of here?”

The other component is the referee. I originally thought the owner was the critical component, and while an absent owner is certainly a meeting red flag, the lack of a referee is a guaranteed disaster.

All active participants in a meeting can instinctively sense progress, and when progress isn’t being made, they get cranky and start looking for the exit. A referee’s job is to shape the meeting to meet the requirements of the agenda and the expectations of the participants. Style and execution vary wildly from referee to referee, but the defining characteristic is the perceptions of the meeting participants. A good referee is not only making sure the majority of the attendees believe progress is being made, they are aware of who does not believe that progress is being made at any given moment. And they’re looking for one thing…

If they’re doing anything except listening, they aren’t listening. There are lots of exits from a meeting that look nothing like a door. Every single moment of a meeting is not going to be interesting to you. When Stan and Richard dive deep on that one piece of code you care nothing about, you mentally wander. You reach into your back pocket, pull out your iPhone, check your mail, and you think, “Let ‘em wander… they’ll be back to the interesting shortly.” Two screw-ups here:

1. You’re the referee and you’re checked out. You’re the guy running down the hallway to figure out whether Stan is going wreck your weekend with crap code. You’re the referee because you have the incentive to drive this meeting to some reasonable conclusion and… you’re checking your mail.
2. You aren’t listening. This is what you’re hearing “Blah blah blah Jira blah blah scales linearly blah blah”. Thing is, there might be value in the blahs, but you will never know because you’re checking your mail rather than understanding where this meeting is headed. Worse, when the meeting goes off the rails due to your lack of attention, you have less of a chance of bringing it back because… you were mentally elsewhere.

The rule is for everyone in the room: if their attention is elsewhere, they aren’t listening. Frank, the guy who plays Plants vs. Zombies during staff and swears he’s listening? He’s not. He’s getting 50% of what’s being said, and worse, he’s giving everyone else in the room permission to slack.

However, the problem here isn’t with Frank, it’s the referee. Frank is not sensing progress, so Frank has left. The referee has forgotten…

If steam isn’t coming from their ears, they might stop listening. It is the responsibility of the referee to constantly be visually surfing the room to determine who is and isn’t engaged. This is hard.

Referee. Solid agenda. Seven people. At any given point in the meeting, three of these people are verbally sparring about the topic. In addition to making sure the three active participants don’t kill each other, the referee — in real time — needs to figure out whether the other four are mentally present, and, if not, what to do about it. This is really hard.

This is really hard because refereeing these meetings is incredibly situational. You’ve got seven people, each with their own personalities and agendas. You’ve got whatever mood they happen to be in at that precise moment. And you’ve got whatever topic merits this meeting in the first place. Given all of these fuzzy variables, what possible relevant advice can I give you to keep everyone engaged? Here are a few small tips:

• Pull them back. If they don’t look engaged, steer the conversation toward them and ask them a question relevant to the current state of the topic: “Stan, no code reviews? Really?”
• Reset the meeting with silence. If several folks have checked out, one of my favorite moves is referee silence. When all eyes are on you, count backwards from 10 and watch what happens — Frank is going to look up from Plants vs. Zombies and wonder, “Why’s it so quiet? What’d I miss?”
• Change the scenery. Are you sitting down? Ok, stand up. Have you been writing stuff on the whiteboard? No? Try it. Small tweaks to the scenery might change nothing or they might give someone a nudge out of their mental haze.

A meeting’s progress is measured by the flow, and the referee’s job is keep it moving along at a good clip, which is why the referee sometimes needs to…

Own it. There is a variety of meeting denizens you’re going to encounter as both a referee and a meeting participant. The one I want to talk about is the person who believes it is their moral imperative to contribute to the meeting simply because they were invited. Yes, talking is a sign of active engagement. Yes, you never know what random verbal curveball is going to magically improve a meeting. Yes, this person always talks… every meeting… like forever.

There is a point where the referee becomes the dictator and owns the meeting. They own it. They actively demonstrate control of the meeting, and when you’re the person who gets owned, it stings a bit, but this meeting is not about you. It’s about each and every person sitting in the room wanting to get out of this meeting where real work is done.

For the referee, the decision to step in and shut someone down during a meeting isn’t one taken lightly. A good referee knows that abuse of the dictator role eventually results in everyone shutting down, which is just as inefficient as that one person who never shuts up. Summoning the dictator effort is a last ditch effort geared at fixing the problem right now, but doing it in such a way that the problem doesn’t show up again. It’s a gut referee call that you’re going to screw up before you perfect, but an important and immeasurable part of running a good meeting involves…

Improvisation. The solution to whatever the hard problem might be is going to show up in one of two ways: random brilliance or grindingly hard work. The path to either involves a competent referee doing everything I describe above while also knowing when to ignore it.

A good referee knows:

• The meeting is nowhere near the stated agenda, but everyone in the room is showing all the non-verbal signs of progress, so screw it, let’s see where it goes.
• This person who appears to be rambling and wasting everyone’s time is onto something that might lead to random brilliance, so let them ramble.
• The glaring danger signs for a meeting that is doomed whether it’s a lack of preparation, the absence of a key player, or the fact the team is wound up about another issue entirely.
• The courage it takes to stop this meeting five minutes into the scheduled hour because there is no discernible way to make progress.

Meeting management, like people management, is often the art of managing a moment, which means that the only rule that applies is entirely dependent on the snowflake-like context of the moment.

A Culture of Meetings

Somewhere in the evolution of a growing company, meetings take over. At the time, it seems like a good idea because the product roadmap is all over the floor, key people are quitting, or there’s lots of yelling in the hallways. Whatever the disaster, a single well-led, efficient meeting with the right people provided a solution to a hard problem. Those who were watching noticed and thought, “Alright, we now have a new tool to solve problems — it’s called a meeting.”

With this fresh sense of validation, meetings spring up all over the place. They become the fashionable solution to problem solving — to making progress. More folks are invited to these affairs because everyone believes that if you’re invited to a meeting, you are somehow more professionally relevant. People start becoming scarce around the building, checking someone’s free/busy schedule becomes part of the culture, and suddenly we’re worrying more about the care and feeding of meetings than getting shit done.

Meetings must exist, but meetings cannot be seen as the only solution for making progress. If you must meet, start the meeting by remembering the definition of a successful meeting is that when the meeting is done, it need never occur again.

Pick-Up

Weather permitting, the Netscape pick-up roller hockey game has been played every Saturday since 1996. 14 years. This hockey game has outlasted all but one of my former employers.

This is pick-up hockey. If you were to arrive with skates, stick and protective gear, you would discover a chill game where the expectation is that you’re going to sit, stare at the game for a few minutes, figure out the rules, and then start playing.

This is chill hockey. We don’t keep score. There is bumping and nudging, but rarely a fight, and the rules few:

1. Offsides are enforced.
2. If the puck leaves the surface, whoever gets it, gets to play it.
3. Don’t be a jerk.

Hockey has a slew of other rules regarding tripping, high sticking, and cross-checking, but in the pick-up game, those rules fall under #3 — don’t be a jerk. When new individual players arrive and they deviate from these rules, they are quickly and efficiently educated. Yeah, we don’t play that way.

This was organically understood until Campbell showed up.

The Campbell game wasn’t 14 years old, but it had been around. I’d played at their converted parking lot a few times. Slightly faster game, more testosterone, and a bit more yelling, but most certainly hockey.

The Campbell game was shut down when their parking lot vanished. We’d seen the occasional Campbell player at the Netscape game, but when their rink vanished, they showed up en masse and that’s when our game went to hell.

In a game where I could count the number of fights in a decade on a single hand, we had two fights in a day. Arguments erupted regarding offside enforcement, whether to use a puck or a ball, the proper timing of line changes — it was a mess. What had been a decade of reasonably chill hockey transformed into a tension-filled game where we were suddenly… keeping score?

The reason the chill hockey game remained so for so long was due to social momentum. The collective will of the 14 veteran players already on the rink far outweighed the will of Joe the New Guy. When he showed up, he listened, he watched, and he quickly discerned the rules of our game because he wanted to play.

When 14 Campbell players showed up on the same Saturday morning, they brought the Different and the manpower to enforce it. It’s not that they didn’t care about local customs, they were willing to adapt, but there was enough of them to represent their version of the Different so they had less incentive to adapt, so arguments and fights erupted regarding unspoken rules.

As Keeper of the Chill, your role as a manager or just the guy who wants the game to go down without fisticuffs requires you not only to publicly define the rules, but also understand why they exist and how they evolve.

Uncomfortably Different

Whether it’s one person or many, when new folks join the team, they are in social shock. Everywhere they look, there are new faces that are speaking a strange language full of curious proper nouns and baffling acronyms. Every single detail is slightly, annoyingly, and uncomfortably different.

In an environment where everything is new, a short set of rules can go a long way to giving new recruits both structure and context about their new home. These rules are designed to give the new folks a basic operating manual for the team to make everyone’s day a little easier.

Now, I have an irrational knee jerk reaction to bad rules. In my head, a rule says, “You, sir, you can’t do your own thing. You must do it this way,” and that is not what a good rule embodies. My negative reaction is due to rule abuse. See, I’m a nerd and I’m predisposed to fucking love rules because a logical and well-followed rule keeps the well-defined system functioning smoothly. It keeps us on the same page, it sets expectations, and it makes the world a more predictable place.

Problem is, people abuse rules. They think because they have authority, they can define a rule to support their particular agenda. People think “This is way we’ve always done it” is a reason to continue to do so in perpetuity. When these folks are cornered and asked, “Why does this rule exist?” we all discover their unsatisfying crappy answer and rules get a bad rep.

A Defensible Rule

My first bit of advice in defining a rule set is to not get lost in the process. You’re likely already a company of 10 or more people, and many of these rules are already understood by the existing team — they are part of your DNA. You do not need to form a committee and schedule seven meetings in order to define a good set of operating rules. In fact, I see no reason why you shouldn’t be able to spin around in your chair and starting writing them on the nearest whiteboard:

• Anyone who interviews a candidate can veto the hire.
• We leave it to the developer to decide when they need a code review, but when they break the build, they’re in the code review penalty box.
• If you have questions about the development environment, you look at the wiki before you spam the mailing list. When you find the answer to your question, you update the wiki.

These are examples off the top of my head and may not apply to your development organization. Just as each team has a different vibe, so will they have different rules, but as you’re considering your list, think about this:

• In your day, where are there points of friction?
• Where would clarity make you less angry?
• What critical parts of the day need to be explicit?
• Where does the team constantly screw up?
• What meeting do you repeatedly have that could be killed by simply defining a rule?

For items on this list, you have two sanity checks.

#1 Is this rule defensible? Can you explain in great detail to anyone who wants to know the current and relevant reasoning for this rule? The reason every single bug has an assigned milestone is so that we know when we expect to address it. A blank milestone not only means we don’t know when the issues will be addressed, it means no one has taken the time to triage the issue and make a call. We value completeness and quality.

#2 Is this rule obvious? You’ll know you’ve hit the mark on a rule by vetting it with the existing team. If you’ve successful defined the rule, their reaction will be, “Duh, everyone knows that”.

Values, Not Rules

It’s worth noting that in many years of software development, I’ve never seen this type of list written down. The unspoken expectation is that new hires are expected to discover and understand this list via social osmosis. As a means of understanding a team, it’s an essential exercise, but defining this list does not replace the exercise of discovering what it means.

These rules are your values. These rules might not be mission statement-worthy, but then again, you’re not defining these at the senior management junket at the Half Moon Bay Ritz-Carlton. These are rules that affect your every day.

- Anyone who interviews a candidate can veto the hire — We value everyone’s opinion. We take hiring seriously. If you’re part of the interview team, you’re responsible for building this company.

- We leave it to the developer to decide when they need a code review, but when they break the build, they’re in the code review penalty box. We value your judgement and we understand that people make mistakes. If you make one of these mistakes, we’re taking reasonable action to prevent future mistakes because your daily actions affect the productivity of the entire team and the quality of product.

- If you have questions about the development environment, you look at the wiki before you spam the mailing list. When you find the answer to your question, you update the wiki. We value communication and we value efficiency. While we want you to move as quickly as possible, we document our collective knowledge because documentation scales better than our time.

Just because you made a list of rules doesn’t mean you’ve explained their value. The new folks still have to discern from the group why the rules matter. In the meantime, these rules keep them on the rails.

They Didn’t Know

After a particularly feisty Saturday game, I typed up the rules for the hockey game and stapled a copy to each of the benches:

• We play with offsides. If you don’t know what offside is, ask.
• We don’t do timed line changes, skate hard and then give someone else a chance.
• If the puck leaves the surface, whoever retrieves it gets to play it.
• Don’t fight. This is pick-up hockey.

Rules are not constraints, they are optimizations and they are clarifications. They are designed to describe what is possible or allowable and rules are not fixed in stone. When Campbell showed up the next week, we didn’t keep score, but after two weeks of ignoring the guy who compulsively and vocally kept score, we discovered a new rule — keeping score is more fun.

The Twinge

You know this meeting. It’s the meeting that when anyone hears the attendee list, they instantly know, “Oh, it’s that meeting”. Something is up: a product is at risk, a strategy is being redefined, or a decision of magnitude is being considered.

Slide reviews are conducted via email, rehearsals are performed, and demos are fine-tuned. When the day arrives, the room fills, nervous glances are exchanged, and it begins. Your practice pays off. Expected questions appear and are quickly answered. The project is solid; perhaps there is no need for that massive decision. We’re in good shape, except Allison, the SVP, has a question. Allison?

“Has anyone talked to Roger’s group about this? Can they support this load?”

Shit.

The Screw-Me Scenario describes the amazing silence in the room when everyone understands the colossal gap that Allison’s questions unexpectedly illuminate. That’s a good article to read if you want to figure out how to react. The question I want to answer here is how in the hell does a SVP who isn’t even a part of this project, who was invited as a courtesy, and who has never even see the project proposal find the biggest strategic gap in our thinking after staring at our slides for 13 minutes?

She had a Twinge.

Twinge Acquisition

As a manager, you manage both yourself and your team, and the simple fact is there will always be more of them than of you. Unless you’re the guy managing a single person (weird), you’ve got multiple folks with all their varied work and quirky personalities to manage.

Rookie managers approach this situation with enviable gusto. They believe their job is to be aware of and responsible for their team’s every single thought and act. I like to watch these freshman managers. I like to watch them sweat and scurry about the building as they attempt to complete this impossible task.

It’s not that I enjoy watching them prepare to fail. In fact, as they zip by, I explicitly warn them: “There is no way you’re doing it all. You need to trust and you need to delegate.” But even with this explanation most of these managers are back in my office in three weeks saying the same thing: “I have no idea how you keep track of it all”.

I don’t.

In addition to trusting those who work for you by delegating work that you may truly believe only you can do, management is also the art of listening to a spartan set of data, extracting the truth, and trusting your Twinges. When you do this well, you look like a magician, but when you screw up, the consequences can be far ranging and damage the project as well as your reputation with those involved.

How to Build a Twinge

Before I explain how this truth extraction and Twinge construction can really screw things up, let’s first understand why these managers aren’t listening to me and why I’m ok with that. Remember, I’m talking about engineers here. A class of human being that derives professional joy from the building of things — specific things. Things they can sit back and stare at — look there! — I built that thing.

The building of things scratches an essential itch for engineers. It’s why they became engineers in the first place. When they were six, their Dad handed them two boards, a nail, and a hammer and they started whacking. BLAM BLAM BLAM. Even with the nail awkwardly bent in half, the wood was suddenly and magically bound together: a thing was built. At that moment, this junior engineer’s brain excreted a chemical that instantly convinced them of the disproportionate value of this construction. This is the best wood thing in the world because I built it. And then they looked up from their creation and pleaded, “Dad, I really need more nails”.

Dad handed them three more nails, showed them where to hold the hammer, and demonstrated how to hit the nail. More whacking. BLAM BLAM BIFF. This time the nail wasn’t bent, this time on the last hit the nail slid effortlessly into the wood. This engineer in training had now experienced two essential emotions: the joy of creation and the satisfaction of learning while gaining experience, perfecting the craft.

Engineers are wired to learn how to build stuff well, and as they continue to do that someone eventually thinks it’s a good idea to promote them to become managers. These new managers initially believe the essential skills of building that made them successful as engineers will apply to the building of people, and they don’t. It’s their experience that matters.

Management is a total career restart. One of the first lessons a new manager discovers, either through trial and error or instruction, is that the approaches they used for building product aren’t going to work when it comes to people. However, this doesn’t mean all of the experience is suddenly irrelevant. In fact, it’s that experience that creates the Twinge.

A Day of Stories

As a manager, think of your day as one full of stories. All day, you’re hearing stories from different people about the different arcs that are being played out in the hallways and conference rooms. As these stories arrive, there is one question you need to always be asking: do you believe this story? Before you make that call, there are a couple things you need to know.

First, this story is incomplete, and you’re ok with that. Here’s why: for now, you need to trust that those who work with you are capable of synthesizing a story. Part of their value is their judgement in presenting you with the essential facts, and until they prove they can’t synthesize well, you assume they can.

Second, and contradictorily, while I believe that folks don’t wake up intending to construct lies, I also know that for any story you’re hearing, you’re getting the version that supports their chosen version of reality. As a story is being told to you, the opinion of the storyteller is affecting both the content and the tone. Their agenda dictates what they are choosing to tell you. Again, malevolent forces are not necessarily driving the storyteller. They are hopeful, they want to succeed, but this story needs judgment, and that’s where you come in as a manager. I’ll explain by example.

A Familiar Nail

“Ok, Project Frodo — we’re two weeks from feature complete. Our task list is down to seven items, but as you can see from this chart, the work is spread out among the teams. I’m confident we’ll hit the date.”

This sounds like good news. This sounds like the truth. Nothing in those three sentences is setting off any alarms in my head, but I’m a manager and it’s my job to sniff around.

“Is the design done?”

“Yes, except for items six and seven.”

Ok, so it’s not done. “When will they be done with design?”

“In a week and half.”

“And you can get the tasks done in the two days after we receive the designs?”

“I, uh…”

Sniffing around pisses people off. Sniffing around is often interpreted as micromanagement, a passive aggressive way of stating, “I don’t believe you can do your job.” While there are a great many managers out there who pull this move as a means of pumping up their fading value, this is not what I’m doing — I’m trying to figure out if this story is familiar.

I’ve built a lot of teams that have built a lot of software. I know that what we receive as complete designs is usually 80% of what we actually need. Because I was the engineer sitting there staring at the Photoshops in the middle of the night with two days to feature complete, thinking, “It’s sure pretty, but what about internationalization? And error cases? You know that’s work, right?”

It’s not that I know all the intricacies of Project Frodo and I don’t want to know them. It’s a team full of personalities, tasks, and dependencies that I could spend my entire day trying to understand, and I’ve got two other projects of equal size that are running hot. As I’m listening to this story, I’m listening hard and trying to figure out… have I seen this nail before? I have, haven’t I? I don’t remember when, but I do remember the Twinge…

Do you remember every success and failure? No. You can recite your greatest hits over a Mai Tai, but I don’t think you can actually recollect them all. However, this doesn’t mean you don’t remember the experience. I’ve long since given up trying to understand why one story rings true to me while another triggers the Twinge. My belief is that my brain is far better at subconscious analysis, pattern matching, and teasing out apparently essential details from the noise than I’ll consciously ever be. My belief is that my experiences drive my sometimes subconscious instincts, and this is why I’ve come to trust the Twinge.

A Twinge Catastrophe

A Twinge is your experience speaking to you in an unexpected and possibly unstructured way, and while you don’t want to base your management strategy on these amorphous moments of clarity, I do want to explain their importance in the organization.

This story telling, the careful selection of facts, ideas, and data, is going on everywhere in the company. Everyone is building a story about what and how they’re doing, and they’re often optimizing in their favor.

While many of these stories involve the mundane day-to-day operations of the company, some of these stories are terribly important. While it might not sound like it right now, that story Bob just explained about a small performance issue on one server is actually a massive performance debacle in the making. Joe’s story about that annoying interaction design problem is actually the description of the absence of a feature you don’t even know you’re missing.

When these seemingly benign stories are not judged, when they are not questioned, the story is over. Bob’s conscience is clear because he gave you a heads up. Your conscience is clear is because you listened to Bob’s concern, and, yeah, you had a Twinge, but Bob’s delivery record is impeccable, so Twinge be damned, it’ll sort itself out in the end.

Your failure to heed your Twinge is a management failure.

It gets worse. This story optimization is happening at every layer of management and in every group of people. Each time an unheeded Twinge story jumps from one person to the next, a lie is being propagated throughout the organization. And if the story started in your group, it’s your fault this misinformation is running amok. Now, there are other people in the building who might get a Twinge and save your team’s collective professional ass, but again, if it’s a story that originated in your group, the responsibility was yours.

Just Another Nail

New engineering managers wrestle with the gig because they miss building stuff. The powerfully addictive act of building is no longer part of their day and they bitch: “You know, I don’t know what I actually do all day.” Finding other ways to scratch this itch is a topic for another article, but for now one of your jobs is to listen to the stories, map them against your experience, and when there’s a Twinge, you ask questions and you need to believe the asking of these questions is a form of building.

As a manager, when the story doesn’t quite feel right, you demand specifics. You ask for the details of the story to prove that it is true. If the story can’t stand up to the first three questions that pop your mind, there’s an issue.

You don’t run a team or a company on a Twinge. The ability to listen to random stories and quickly tease out a flaw in the logic or the absence of a critical dependency is just one of the skills you need to develop as a manager. Like building, both the discovery and the asking of these questions is an art; it’s just another nail you need to figure out how to hammer.

Knee Jerks

There was a fight on the roller hockey rink this morning. Anaheim bumped into Philadelphia at speed and Philly didn’t like that so he elbowed Anaheim in the chest — hard. Anaheim pushed back, shoving Philly into the goal where he tripped and fell. Swearing, more shoving, and then we spent the next five minutes keeping them separated.

This hockey rink is a remnant of first Internet bubble. Built by Netscape, the rink has held a game every Saturday since 1996. A majority of the folks who show up know each other, so the game is mellow. Finesse, not fighting. A fight is an unusual once a year thing.

When Philly, who I believed was at fault for this whole situation, got the bench, someone asked him what happened. His answer, “Anaheim ran into me and I protected myself.”

One Eighth of a Second

I want you to think of the last time you were surprised. Good, bad, I don’t care. When was the last time you were really surprised? Got it? Ok, now think about the very first thing that you thought about the surprise. I don’t want to know how you eventually handled it; I want you to think about your instantaneous first reaction.

How do you react when you’re surprised? Is this how you always react when a surprise lands? My guess is yes.

On the hockey rink, Philadelphia puts up his shields when he’s surprised. It’s a natural reaction, protecting yourself, but what’s interesting isn’t Philly’s very sensible reaction to the perception of being attacked, it’s everyone else’s interpretation. We all saw him hold up his arms in defense of Anaheim’s unintentional attack and we all thought, “Man, Philly. What a goon.”

In any group of people larger than one, these instantaneous reactions to unexpected situations happen a lot, and understanding their range and impact is important to navigating awkward, tension-filled, and professionally tricky situations.

The Jerks

These are knee jerk reactions, and the first thing you need to know about them is that they should be first viewed without judgement. I’m not a psychologist and I don’t know why some people are aggressive knee jerkers and others are passive. I don’t know if these reactions are a function of upbringing or genetics, but I do know that we as a species have little control over these initial reactions and there are many of them.

In my head, the complete set of reactions fit on a spectrum that is labeled Fight or Flight. The first step in understanding a knee jerk reaction is first figuring out where on this spectrum the reaction lies. Is this a person who is going to take on the surprise or are they going to let it wash over them? Will they bolt? Will they wilt? If there is one thing you want to know quickly about those around you, it’s their penchant to fight the surprise or flee it.

Again, no judgement. A person who automatically has the fight instinct is not necessarily a jerk — it’s just the default instinct when the world unexpectedly and rapidly changes. I know who on my team will attack a surprise. They’ll leap on it. I also know the ones who will silently digest the surprise. I know who is going to come back three hours or three days later with a totally different attitude because they’ll have actually processed the surprise.

The base assessment of fight or flight gives you a starting point regarding what might first happen when a surprise lands, but there are other instantaneous reactions that occur and understanding them gives you an idea of what you need to do next, if anything.

For the sake of this article, my assumption is a surprise has landed and it’s bad news. These reactions apply regardless of the type of surprise, but let’s assume it’s professionally bad news with negative consequences and it’s being delivered in a group setting. Here’s whom you might see across the table:

Dr. No. Denial. That’s the reaction. Doesn’t matter if the surprise is reasonable, understandable, or well explained. Dr. No’s only reaction is a fighting “No”.

• “No, I’m not going let her go.”
• “No, I’m not moving organizations.”
• “No, we’re not shutting down this group.”

Remember, knee jerk reactions are not rational, they are not considered, and while they are tactically interesting, they are not strategically useful. Dr. No’s denial is not her actual thoughts on that topic, it’s her reptilian brain reaction to a surprise.

No.

If this is a group surprise and Dr. No is sitting in a conference room full of people throwing down the No, there’s a chance for everyone to go off the rails. Well, Dr. No said no and I agree, so NO AS WELL. The time immediately after the surprise goes down is not the time to take any action except to allow folks to react. There are going to be Nos as well as a bevy of other reactions and your job, if it’s your meeting, is to let folks talk — let them react. The goal with Dr. No and everyone else in the room is to get their reaction out so that we can figure out what to do next.

The follow-up: The good news is that Dr. No has got it out of her system. She’s expressed her displeasure, which is half of the game. The next time you chat, there will be residual No, but Dr. No knows that she’s been heard and will be willing to brainstorm what to do next about the surprise.

Raging Bull. Perhaps the most dangerous of the reactions, Raging Bull wants to fight. They’re taking the surprise personally, they’re going to say No, and they’re going to pick a fight. The Raging Bull is Dr. No with attitude.

The move with the Raging Bull is to know that it’s coming, to know that you’ve got a Raging Bull on your hands. If you have any control over the surprise, you want to put the Raging Bull in a safe situation where they can react to their heart’s content without afflicting psychological damage on others or sparking a mob mentality where they infect a mindless horde of mini-Raging Bulls. If it’s a pure surprise and it’s a group setting, my advice is to end the meeting as quickly as possible. Like Dr. No, Raging Bull is expressing his shock. Unlike Dr. No, the Raging Bull isn’t going to feel complete until they’ve got the emotional satisfaction of picking a fight with someone else.

The follow-up: Everyone needs time to contemplate a surprise, but no one needs time more than Raging Bull. Each knee jerk reaction scratches a particular psychological itch and in the case of Raging Bull, they believe that getting someone else to participate in their mental and verbal freak-out is somehow going to help.

It’s not.

Of all the reactions, Raging Bull’s behavior is the one that I’ve found to likely to repeat itself after the fact. Raging Bull will often continue to pick fights days after the initial surprise, which is why it’s your move to get them thinking, as quickly as possible, about what’s next. What are we going to do about the surprise? What specific thought does Raging Bull have which is crucial to successfully navigating this surprise?

Still Water. This reaction reads like flight because they’re not fighting. In fact, they’re just sitting there, but Sill Water is taking it all in. They’re not missing a thing and in their complete silence, wearing their poker face, they are meticulously processing, they’re evaluating all possible permutations, best and worst case scenarios, and potential impact on their day to day.

This processing results in one of two very different Still Waters. There’s the true Still Water who is going to maintain the calm demeanor for the entire duration of the surprise. See, this Still Water’s processing has resulted in a comfortable plan. They believe they know what to do about the surprise and this realization has brought them peace.

The second Still Water is mentally losing their shit. Sure, externally they look calm, but internally their processing has resulted in increasingly loony nightmare scenarios regarding the surprise. Without quick action, Insane Still Water will find reason to become a Raging Bull.

The follow-up: You want to get to Still Water as quickly as possible in a safe location after the surprise because Still Water isn’t still. Unlike Dr. No and the Raging Bull who had their opportunities to weigh in, Still Water is still in their head and the longer they remain in the head, the higher the probability they’ll tell themselves a tale that will drive them insane.

You need Still Water to say out loud how they feel about the world suddenly changing. Like Raging Bull, you need to engage Still Water in the surprise and move the problem out of their heads and onto the table where everyone can take action.

Distiller. This is my favorite knee jerk reaction because the Distiller attacks the surprise with questions. Why did this happen? How come we didn’t see it coming? Ok, what’s the impact? Right, what are we going to do?

This is a fight reaction, but a constructive one. The Distiller is as uncomfortable as anyone with the surprise, but their coping mechanism is aggressive understanding. They’re not going to stop asking questions until they feel they’ve got a complete understanding of what actually happened.

In a group setting, I let the Distiller have free-reign during the landing of the surprise because their incessant questions are helping everyone in the room contemplate what actually happened. They focus the surprise on facts rather than feel.

The follow-up: You’re going to feel you’ve got a good idea where the Distiller is at because of their endless questions, but now’s a good time to explain that everyone comes down from a surprise in different ways, which is why everyone needs that personal follow-up. Yeah, a Distiller can turn into Raging Bull after a night’s sleep. Still Water might go Distiller. You just don’t know who is going to walk into the building 24 hours after the surprise. This is why most surprises are engineered to occur late in the week; there’s a belief that all the knee jerks are going to calm down over the weekend. Maybe. More on this in a bit.

The Handler. The first flight reaction sure doesn’t feel like flight. The Handler is not surprised. In fact, they’re fired up to handle whatever the surprise might be. They make it appear that they knew this surprise was going to occur. How’d they do that?

The Handler is a calm facade. Where the Distiller understands via questions, The Handler’s coping mechanism is the illusion they’ve got it all figured out — that they’re 10 steps ahead of everyone else. This is a convenient reaction when you’ve got the Raging Bull standing on the conference table challenging anyone to hand-to-hand combat, but The Handler needs help.

The follow-up: The Handler crumbles hardest. The Handler is actually Dr. No except without the denial. There will be a quiet moment in the middle of the night when The Handler realizes absolutely nothing has been handled and then you’ll see their actual reaction.

My Bad. This flight reaction is one of accountability. My Bad’s impression is that they’ve personally done something to incur this particular surprise. They believe that if only they had done just one thing different, no one would’ve had to deal with the surprise.

There’s hope inside of My Bad’s reaction. Their empathy regarding the surprise is constructive, as opposed to the destructive social tendencies of Dr. No or Raging Bull, but you don’t want them wallowing in their overdeveloped sense of accountability.

The follow-up: My Bad is not responsible for the surprise. While their sense of responsibility is admirable, My Bad needs to understand the actual cause behind the surprise. They didn’t cause it, so they shouldn’t feel it. They more they focus on feeling responsible, the less energy and focus they have for making progress.

We’re Doomed. The most common flight reaction is also the reaction that, I believe, everyone is going to experience as they digest the surprise. Despair.

In a room full of geeks hearing a surprise for the first time, one of their first thoughts is, “How does this surprise fit into my mental system of how things work?” Failure to map the surprise into the mental model results in an uncomfortable realization: “The world does not work as I expected. Therefore, other surprises are guaranteed to happen randomly. QED. I have no control whatsoever. Shit.”

The follow-up: A perceived lack of control or understanding of our world is a confidence shattering experience for the geek, and the best way to attack this despair is with a project. Doesn’t matter if the project is surprise-related or not, the geek needs something to do. They need the blissful distraction of building something. It’s during this constructive distraction that they’ll actually figure out how they feel about the surprise.

I Quit. The last knee jerk is our strongest flight reaction. An extreme version of We’re Doomed, I Quit does exactly what you’d expect: they threaten to quit on the spot.

They’re not quitting. Well, they might, but not right now. You need to translate “I quit” into what they’re actually saying: “I am very surprised and I don’t like being this surprised.” It’s unfortunate that this is their reaction, especially in a group setting, because I Quit’s attitude can create mass professional hysteria, which means this needs to be handled immediately. You can’t wait until after the weekend to explain to I Quit that their reaction at this moment might be vastly different after a night’s sleep. You need to hold up a mirror in front of them and ask, “No matter the surprise, why in the world would you eliminate so many options by quitting on the spot?”

The follow-up: I Quit will calm down and land on another opinion, but their knee jerk reaction is a sign of a larger problem. I don’t know what your surprise is, but I know if someone wants to quit that, first, it’s a big surprise, and second, they value their job second to their peace of mind.

Stages of Jerk

With people, it’s never as easy as just a name. These labels for the knee jerk reactions are deliberately simple, but people are conspicuously complex.

As I hinted earlier, I’ve found it commonplace that you’re going to see multiple knee jerk reactions as a corporate surprise is comprehended. These reactions, like grief, have stages, and your job as a manager or a concerned co-worker is actually not comparably complex. Your job is to listen.

The reason there’s a knee jerk reaction is because the unexpected occurred. It kicks off the process of assimilation and that’s what we care about — the understanding of the surprise, not the reaction to it. While everyone has a different reaction, they’re all going to end up trying to figure out what just happened, and part of that process is having someone they trust sit there and listen to their assessment. Verbally walking through our thoughts is one of the ways we organize and understand them and begin the process of finding a comfortable constructive conclusion.

I’m just as uncomfortable with a Raging Bull as anyone, but I know this knee jerk reaction is not who they are, this is just how they react. Understanding these varied potential reactions is just the first part of digesting a surprise - it helps you understand what to expect so you can begin to figure out what to do next.

Wanted

Jesse walked.

Monday is the day we set aside for new hires. All the new hires spend the morning learning about the company, figuring out how to create accounts, and becoming indoctrinated in company culture. When lunch time arrives, managers pick up their new employees and take them to lunch.

Their morning starts at 9am, and at 9:15 I got a call from HR: “Jesse’s not here”.

Bad traffic, miscommunication, there were a dozen good reasons he wasn’t there, but I instantly felt a rock in my stomach: “Jesse walked”.

A quick call to my recruiter and the mystery began to unfold, “Oh, yeah, he called just before 5pm on Friday and said he wanted to chat. I was off Friday, should I call him now?”

Yeah, call him. Tell me what I already know.

The recruiter discovered that Jesse was firmly ensconced in a cone of silence because his Friday call was his cold feet call. After three months of phone screens, interviews, offer negotiations, and acceptance of said offer, Jesse was calling to tell us that while he had resigned two weeks ago, a last minute counter-offer had shown up, and he’d decided to stay… at 4:45pm on his last day.

Jesse walked.

As I sat at my desk, lightly tapping the phone headset against my forehead, I thought how simple it would be to be pissed. In terms of respect, trust, and professionalism, Jesse had screwed me in just about every manner possible, but, in this case, the fault would be mine.

I had not explained to Jesse that he was wanted.

The Requisition Situation

This article is going to talk about the beginning and the end of the hiring process. I’m going to make sure you know two things. First, that you understand how urgent it is that you hire, and second, how to make sure those you hire actually show up. There’s a huge pile work in the middle of this process involving phone screens, interviews, and offers, but for this article we’ll just focus on the beginning and the end.

Let’s start by understanding where this whole hiring process starts. We need to talk about requisitions.

In many companies, jobs are ruled by requisitions (“reqs”). These imaginary pieces of paper give you, the hiring manager, the permission to hire, but they serve two other purposes. First, they document and formalize the process of hiring a new full-time person, and more importantly, they give executives visibility into the state of the company’s growth.

It varies by company, but reqs, specifically open, approved reqs, are one of the more popular organizational levers the execs have to control of the growth of the company. In software development, one of your larger corporate expenses is base salary, which means the moment uncertainty appears on you company’s horizon, reqs (read: potential large expenses) are one of the first things to vanish.

This leads to the most important rule regarding requisitions:

Reqs vanish randomly, often without notice, without reason, and at the least convenient time.

In larger companies, the bureaucracy involved in actually getting an approved req is impressive. When the req is finally approved by the 17th person you don’t know, you have a false sense of accomplishment. You believe this req is yours, but there is really only one way to make it yours — make the hire.

It’s not just corporate nervousness that causes reqs to vanish. Your boss, who you love, is a likely req stealing culprit. Anton’s got a guy right now who is perfect for his team and we’ve only got one req. He can hire him right now and I swear we’ll get you a req when you find someone.

You believe your boss. You trust your boss, so you give him your req and Anton’s a happy guy and you feel like you’ve done the team a solid. Except when you actually find someone, guess what, you don’t have a req. Neither does your boss because some time between when you gave your req and actually found someone for your position the first rule was invoked: every single req in the company was frozen.

I’m guessing 50% of the reqs I’ve managed to get approved in my career have resulted in a hire. Meaning, a flip of a coin would as accurately predict whether or not I’d be able to hire someone.

From the moment there’s a hint of an idea of a req in your future, you need to work on improving your chances that you’ll be able to hire. And that means, as quickly as possible, you need to: find the person, phone screen them, interview them, interview them again, negotiate an offer, get that offer accepted, and get them in the building. Think of that as you’re staring at your shiny new req. Think that the industry average for hiring against an approved req is 90 days — three months — and each of those days represents a day that someone, somewhere can steal your req. This is why you need to…

Spend an hour a day on each req you have

We’ll talk about how to make sure they’ll show up in a bit, but to start you need to get the pump primed. A former boss helpfully suggested, “Spend an hour a day on each req on your plate”.

An hour?

If you’ve got an approved req, you have approval to grow you team. To add new skill sets. To build more stuff. In your role as a manager, I ask: “What’s more important than growing your team?” No, this isn’t a draconian hour; this is a daily reminder that you need to grind away at this req until you’ve hired someone.

Rands, I have no candidates yet. The req was just approved. I…

Again, reqs vanish. Randomly. At the end of each workday, you need to think, “Phew, no one stole my req.”

Here’s how to start:

• Search the web for candidates. — Show me a stranger who will be perfect.
• Mail friends who might know the perfect person. — Know anyone? How about you?
• Annoy your recruiter. — Where are my resumes?
• Ping folks who have turned you down in the past. — Are you ready now?
• Scan your inbox and sent folders for folks you need, but may have forgotten. — Really, are you ready now?
• Read your job description for additional inspiration. — Do I actually know who I’m looking for?

But isn’t this why I have a recruiter?

It’s terrific that you’ve got a recruiter. They’re going to streamline your entire hiring process, but you still need to spend an hour a day for each req. A quality recruiter is going to find candidates, do time-saving phone screens, and they can keep in-flight candidates warm. When it comes to offer negotiation, they’re great at providing you essential compensation telemetry and they’re good at playing bad cop, but as we’ll see, it’s your job to demonstrate that the candidate is wanted.

I found them! I’m done!

No, you didn’t, and no, you aren’t.

No really! He verbally accepted, he starts in two weeks. It’s a done deal.

No, it’s not. If randomly vanishing reqs are painful lesson #1 of hiring, painful lesson #2 is: people lose their flippin’ minds during job transitions.

Think back to your last job transition. Think about the mental turmoil. When did you actually fully believe that you were going to accept the new gig? For me, it’s about two months after I started.

You keep recruiting; you keep searching for the perfect employee until your new hire is sitting in their office. It’s not common for an accepted offer to be declined, but it needs to happen once for you to learn the lesson, to suddenly realize, “Oh, I need to start over. Crap.”

Until he’s sitting in the seat, in the building, badge hanging from his belt, you haven’t hired anyone.

Deliberate Want

Michele’s team was embarking on a new technology direction and while she had the basic talent in place, she needed two more hires and we had the reqs. In a recruiting brainstorm, I sketched out the type of person we needed. “Ok, we need Alex. He’s the Sr. Architect at this other company, but he’s the right combination of technical brilliance and architectural jerk. We need someone with that technical ability and the will to enforce it because we’re starting from the ground up.”

Her: “Why not hire Alex?”

Me: “He’ll never leave his start-up.”

“Have you asked?”

“No.”

“I’ll ask.”

She did, and while it took six months, Alex, the perfect fit for the team and for the project, joined the team. Halfway through the recruiting stint with Alex, when it looked like he might not budge, I threw another perfect candidate on her plate and said, “Maybe ask him, too?” Sean was on the team a month after Alex.

Two hires I thought we had absolutely no chance of hiring. Both on the team in a matter of months. Your question is, “What’s her secret?” and the answer is dangerously simple - deliberate, consistently expressed and reinforced want.

Both of the positions we had were attractive. Senior engineering gigs working on a 1.0 product in a name brand company. But these guys were the top of the field. Recognized names. There were any number of opportunities across the Valley that would be attractive. How’d we win?

We continually and consistently explained that they were wanted.

The idea of a new gig, a fresh start, is appealing because of its simplicity. You know nothing about your future team; you have no idea about potential death marches, or that guy down the hall that just bugs you for no particular reason. It’s simple to think about the future optimistically because the future hasn’t screwed you, yet.

This optimism fades in the middle of the night when you open your eyes, startled, and think, “Why in the world would I leave a solid gig with people I know and a bright future?” The reasons are myriad, but that’s not the point. The point is for any big decision, you’re going to question it from every single angle. You’re going to have endless inner dialogues with yourself. You’re going to talk yourself into the gig and then you’re going to talk yourself out of it.

It’s exhausting.

Michele’s message during the entire hiring process was, “You are the best person for this gig. We want you.” Remember that we’re not talking about random, anonymous candidates; we’re talking about handpicked candidates.

Before any interview, she’d drive to them, explain the gig, and begin, “You are the best person for this gig. We want you.” After the first round of interviews, her message was the same, “See, this gig is perfect for you. We want you.”

When we started the offer negotiations, she’d worked with the recruiter and knew exactly what we’d need to do to lure the candidates. She knew that base salary was a big deal for Alex. She knew Sean was going to be a stickler about stock. There was no offer negotiation because Michele constructed offers that were going to be accepted. She presented them: “This is the offer you wanted. This gig is perfect for you. We want you.”

Once the offers were accepted, Michele didn’t change her tone or message a bit. She’d had rockstars walk before and she knew the slippery inner dialogues that were going on. She knew that change begets more change and that the easiest time to lose someone was during that post-courtship purgatory between gigs. She had her team take them to drinks. She planted seeds of future work that would need to be done. She reminded them, “We want you”.

This strategy reads like a massive ego-stroke for an attention-starved engineering rockstar, but it’s not. Whether you have pre-identified a candidate for your gig or you’re lucky enough to randomly find a great fit in a pile of anonymous resumes, the strategy is the same — you consistently remind the candidate that they are wanted. In the mental chaos that is a career change, you and your gig are unchanging in your message. You’re not coddling them; you’re a constant amongst mental chaos.

Hire for Your Career

The strategy I’m proposing steps on a lot of recruiter toes. Recruiters are professional relationship people and their instinctive reads on candidates can be eerily accurate, but their job is the hire and once the hire shows up, the recruiter vanishes. The relationship is ended because the job is done.

Your professional relationship with those that you hire is never over.

If you’re hiring well, you’re hiring people not just for this job, but for your career. These are the people who, for better or worse, will explain to others what it is like to work with you. They’ll explain your quirks, your weaknesses, and your strengths. When they eventually leave the group, they’re taking your reputation with them. You may never talk to them again, but they’ll continue to talk and my question is: what stories are they going to tell?

Your daily hands-on management of your hiring isn’t just going to improve your hiring process, it’s going to improve your career because you’ll demonstrate from the first moment you interact with your future employee that you care.

Jesse didn’t decide to turn us down at 4:45pm on his last day. The decision began long before that and I wasn’t listening. I didn’t hear the parts of his current job he loved because I didn’t do the phone screen. I didn’t understand his concerns about leaving the first job he loved since college because I didn’t build enough trust in the interview. I didn’t hear him drifting away during the offer negotiation. The last thing I heard about Jesse is he walked.

Gaming the System

On my list of creative management solutions to dire situations, I offer the rolling whiteboard.

The rolling whiteboard was a curiosity at the start-up. Not a full size whiteboard, but a door-sized whiteboard on wheels, suitable for rolling into conference rooms and cubicles alike. I never knew who owned it; I just grabbed it in a moment of desperation.

It was end game. The time in the project where you pay for every single shortcut you’ve taken, for every specification you didn’t write, and for all the warnings from engineers that you’ve ignored. All the data is grim. Bug arrival rates are skyrocketing while bug resolution rates are pathetic because, uh, well, engineers are still finishing features.

Like I said, grim.

The endless stream of bad news was grating on everyone. We were already three weeks into working weekends with no end in sight. A normally pleasantly pessimistic engineering staff had gone uncomfortably quiet. Everyone was staring at “the date we can’t miss” and thinking, “I guarantee we’re missing it”.

I needed a game.

An Entertaining System

As I said before, geeks are system thinkers. We see the world as a very complex but knowable flowchart where there are a finite number of inputs, which cause a similarly finite set of outputs. This impossible flowchart gives us a comfortable illusion of control and an understanding of a chaotic word, but its existence is a handy side effect of a life staring at, deducing, and building systems. It’s also why we love games — they’re just dolled up systems — and the more you understand this fascination with games, the better you’ll be at managing us.

As with all mental excursions with geeks, there’s a well-defined process by which we consume a game, and it goes like this:

• Discovery
• Optimization, Repetition, and Win
• Achievement

Discovery — From confusion to control

The initial joy of a game for the geek is discovery. This is a delicate balance of confusion and progressive disclosure. A game is initially attractive because it starts chaotic and unknowable, but even in the chaos, there’s always a hint of the rules… of structure. What are the specific rules that govern this game? And how might I learn them?

A geek is searching for a single source of joy in this initial state. It’s the sense of discovery and progress toward a currently unknown goal. I want to see the engine that defines this particular universe… I want to see its edges. We’re looking for those edges because as soon as we find this wall, we know this is a containable and knowable place and that is comforting because the game becomes a controllable thing.

There’s creative flexibility in rule discovery and pacing, and it tends to be a function of the size and the intent of the game. The beauty of Tetris is that the initial rules are immediately obvious. But the wonderful curse of a massive online game like World of Warcraft is that while there are rules, they are vast and, as we’ll see in a moment, they are changeable.

This discovery is the hook where a geek is going to know in just a few minutes whether this particular game suits their particular appetite. But getting past the initial phases of discovery doesn’t mean you’ve successfully engaged the geek. The real test is…

Optimization, Repetition, and Win — A paradox and a warning

With the basic rule set discovered and defined, the process of optimization begins. Ok, I get how it’s played, how do I win? This is the phase where, now equipped with the rules, the geek attempts to use them to their advantage.

There’s a discoverable structure to the rules. There’s a correct order, which, when followed, offers a type of reward. It’s the advantage of thinking three blocks ahead in Tetris or holding onto those beguiling hypercubes in Bejeweled. This is the advanced discovery of the system around the rules that leads to exponential geek joy.

There’s a paradox and a warning inside of optimization and repetition.

The paradox involves the implications of winning. Geeks will furiously work to uncover the rules of a game and then use those rules to determine how they might win. But the actual discovery of how to win is a buzz kill. The thrill, the adrenalin, comes from the discovery, hunt, and eventual mastery of the unknown, which, confusingly, means if you want to keep a geek engaged in a game you can’t let them win, even though that’s exactly what they think they want.

Think of it like this — does it bug you that there’s an absolute high score to Pac-Man? It bugs me.

To get around this entertainment-killing paradox in subscription-based games like World of Warcraft, game designers freely change rule sets as part of regular updates. The spin is, “We’re improving playability” which translates into, “The geeks are close to figuring it out and we can’t have that because they’ll stop paying.”

This paradox does not apply to all games. It’s hard to argue that there is much more to learn about Tetris, but folks continue to play it incessantly, which leads to the warning.

There’s a socially frightening act inside of optimization that normal humans don’t get and it’s the calming inanity of intense repetition. In a game like World of Warcraft, many of the tasks involve an exceptional amount of repetition. Repetition like, “Hey, go kill 1,000 of these guys and come back and I’ll give you something cool.” Yeah, 1,000. If each kill take a minute, you’re talking about sixteen hours of mindless hacking and slashing. This is not a task that requires skill or thought… and that’s the point.

If you walked in and looked over my shoulder at troll kill #653, you’d think I’d dropped into a twitchy-fugue-like mental state and I have. I am… a machine. Machines don’t have a care in the world, and that’s a fine place to be. This is the act of mentally removing ourselves from a troubled planet full of messy people, combined with our ability to find pleasure in the act of completing a small, well-defined task. This is our ability to lose ourselves in repetition and it is task at which we are highly effective.

In the defense of game designers, there are no quests that read “Go waste sixteen hours of your life doing nothing”. They are more elegant with their descriptions; they splice all sorts of different tasks together to distract you from the dull inanity of large, laborious tasks. But they know that part of what makes us tick is the micro-pleasure we get from obsessively scratching the task itch in pursuit of the achievement.

As I’ve never designed and shipped a game, I can confidently and ignorantly say the compelling magic in games comes from the design in optimization and repetition. This is the portion of the game where we spend the most time and effort and derive the most pleasure. It is this abstract mental state we long for when we’re not playing.

But there is one last phase to consider, achievement.

Achievement — Who cares if you win by yourself?

Once a geek has learned the game by discovering how to win, they become interested in advanced winning. They’re interested in how their win fits into the rest of the world. They want to compare and measure and answer the social question, “Is my pile of win bigger than yours?” They believe they’ve mastered the game, but reputation — achievement — is nothing unless someone else can see and acknowledge it.

Before the Internet, winning was a private thing. You entered your three-letter name into the local Pac-Man machine and then anonymously stumbled off in search of Donkey Kong. In an interconnected world, games became social, and once we discovered each other in these virtual worlds, we looked for a means to compare our feats. We began to understand that achievement was not just becoming great at a game, but being recognized for being great.

Achievement can be as simple as a score, a numeric means of comparison, but the more sophisticated the game, the more complex the achievements. In World of Warcraft, you’ll be busily into your seventh hour of mind-numbing troll extinction when you see that night elf run by with… what’s that? A staff… where the hell did she get that staff? It’s sweet. My world will not be complete until I own that staff. Now, what was four more hours of troll killing becomes the quest for the staff.

There’s no well-defined rule that says, “To win, you need this staff”. Sure, it might make those next 200 kills easier, but that is not your entire motivation. For you, the staff is your own personal badge of mastery, and you don’t wear a badge for yourself, you wear it for others to see.

Most achievements do have an empirical value, but that’s not what makes them important. The point of an achievement is to have someone you know or don’t know look at your Violet Proto-Drake and say, “Holy crap, do you know what he had to do to pull that off?” It’s wondering exactly how far you’ll go to get the Legendary badge on Stack Overflow.

In a world where we spend a ton of time with people we’ll never meet, achievements are the currency of respect and identity.

The Rules of the Game

Now that we understand how games float the geek boat, we can tease out rules you can use to build your own business-centric games. This is will take a creative leap on your part because I don’t know how your particular situation is grim. Perhaps your bug count is crap like mine? Maybe you can’t hire fast enough? Maybe you can’t measure how screwed you are? I don’t know what game you need, but I know you need to follow the universal rules of games:

The rules need to be clear. Whatever game you design must stand up to scrutiny. Test the rules with selected geeks before you roll it out. Find the holes in your game before you’re standing in front of the team describing a game that makes no sense. Ambiguity, contradiction and omission are the death of any good game.

The rules must be inviolable. Enforce rules with an iron fist. A rule not followed is twice as bad as a poorly defined one. A violation of the rules is an affront to a geek. They react violently to violations of the rules because it’s an indication that the system is not working. Rules make a game fair, and when they stop being followed, the geeks stop playing.

The playing of the game must be inclusive, visible, and broadcasted. Include everyone on the team. Those not on the team should be aware of the progress and implications.

Only use money as a reward as a last resort. It’s a knee-jerk management move to use money as an incentive. Problem is, money creates drama. Money makes everyone serious, and while you may be in dire straits as you design your game, you don’t want the team stressing about who is getting paid; you want them to stress about the work.

This is not to say that rewards in a motivational game are verboten, but step away from the money and think about achievements. One of the best trophies I’ve awarded was a horrifically ugly ceramic blue rhino the size of a pit bull. The winner proudly displayed the rhino achievement in his office for years.

It’s not a game. Just because I’m using the word game all over this article doesn’t mean it’s trivial, simple, or something not to be taken seriously. Your geeks will treat the game as a motivational tool as seriously as you choose to treat it in building and rolling it out — because they want to win.

The Whiteboard Game

Everyone was working on a Sunday night as I stared at the blank portable whiteboard in my office. A weekend of hallway conversations, bug scrubbing, and informal testing confirmed what I already knew: the product was shaky, the bugs we were discovering were alarmingly bad, and there were too many of them.

Ok, a game. The game will be called Focus and it will concentrate and structure our attention on the worst parts of the product. I listed the 10 worst bugs I’d found during the weekend on the board. Next to each bug, I drew four boxes:

• Root cause
• Fix identified
• Fixed
• Tested

I grabbed a handful of dry erase pens and rolled the board into the architect’s office and said, “This is all we’re working on”.

He stared at the board for 10 minutes and finally nodded, “Good, but each person needs their own color and you should assign points for each of the boxes. 10 points for root cause and fix identification, 5 for fixes and tests.”

“Points for what?”

“Points for points. We’re geeks.”

“And everyone has their own color?”

“Yeah, so we know who has the most points. Give me a blue pen, I’ve already got root cause on bug #3.”

“Blue?”

“Yeah, I’m always blue.”

No Surprises

At the end of each fiscal year, companies take stock of their performance. How’d we do? Better or worse? This is a natural time to reflect upon individual performance — this is when your boss writes your review.

In my ideal management world, a review is simply a documentation of well-known facts, your performance over the year. It also contains constructive advice and insight regarding how your boss believes you can improve on that performance. My dream is that you already know all of this information because you’ve been getting year-round feedback from your boss.

I wish.

Whether your manager is consistently delivering this information or not, the feedback, written down, is completely different from receiving it verbally. The path to your brain via the written word is dramatically different than for the spoken word. Reading the highs and lows of the past year makes them permanent and makes them real.

And then there’s the surprise.

Show Me the Money

Bad news. The surprise has nothing to do with money. We’re not talking about compensation here. Yes, you did a splendid job this year and I think they should be throwing raises, bonuses, and stock your way. But it’s even better if it’s clear why you think you did a splendid job. Can you articulate it? And you might know, but does your boss? Can he explain to you, in detail, how well you kicked ass?

I didn’t think so.

See, your boss has you and a bunch of other yous who are all allegedly kicking ass, and all of that ass kickery is tricky to monitor, especially over an entire year. It gets even worse when one of your team members is not kicking ass. Legitimately or not, that’s actually where a lot of your boss’ attention is going. You read that right: someone else’s failure is distracting from your phenomenal year.

Let’s fix that.

There are three strategies I’d like you to employ when it comes to your yearly review. They are:

1. Ignore the measures, focus on the content.
2. Prepare for the fact a review is a discussion and, sometimes, a negotiation.
3. Deconstruct the surprise.

Measures versus Content

I’ve experienced a lot of different review formats at different companies, but let’s boil it down to three buckets. A review describes:

1. What you did.
2. How you did it.
3. What you need to do next.

This is a massive simplification of your review. Your review has all sorts of other corporate and division focus areas, but these impressive sounding labels are still just lenses through which you understand how you did versus what was expected.

For each of the buckets, there are two classes of information: the content and the measure. I want to explain how you can save yourself a lot of sleepless nights ignoring the measures, but first, a definition.

Sprinkled across your review are measures. These are words like “Needs Improvement”, “Satisfactory”, or “Excellent”. These words grab you because they’re easy to understand. They are effectively your grades, and you’ve spent a lot of your formative years waiting for grades to show up.

If I told you that you got an A on a piece of work, you’d internally translate that letter into a pleasant, “I did about as well as I could. Go me.” Grades - measures - are efficient, they do convey information, but they lack essential content. I’ll explain via example.

When I arrived at University of California, Santa Cruz in the 90s, they had no grades. Hippies. At the end of the quarter, you received a written evaluation. For each student in the class, the professor or the teaching assistant would produce a written evaluation — a plain English description of the type and quality of the work produced over the semester.

I don’t know who came up with the idea of ditching grades, but my hope was that they wanted to ditch the measures. The intent of measures are not to derive useful information, they are designed to allow for comparison and, duh, measurement. Am I higher or lower than you? How many As? Are there more As than Bs? It’s interesting data and I’m sure if you took a classroom full of data and plotted it on a graph, you’d learn something. Look! A bell curve!

A measure doesn’t help you in your career. Your performance review isn’t about comparisons to others. They’re about what you did and what you could do. What you’re looking for is the content.

Tell me which is more useful:

“You did well.”

-or-

“You finished the work on schedule, the customer was happy with the results, but there were lingering quality issues with the code. Looking at the last two releases, you had 2x the numbers of bugs than in prior releases. Focus on…”

We get hung up on grades, on measures, because they are so gosh darned digestible. They give us the illusion that they show us where we fit, but they don’t tell us what next?

At UCSC, the point of the gradeless report card was to create a vacuum where the professor would actually say something useful. You’re not going to get rid of measures — they serve a distinct purpose — but when you’re first reading your review, I want you to ignore those seductive one-word assessments of your entire year. Their simplicity, while comprehensible, is just going to obscure the complexity of your year.

Rather, look at the content behind the measures. Whatever your particular areas of focus are, does your boss do an effective job of explaining what you did, how you did, and what you could do better? It’s a simple set of requirements, but your boss is going to mess it up, which is why you need to be clear that…

A Review is a Conversation

The written word is intimidating. An assessment of a year is a big deal, so what are you going to do when you sit down with your boss and he hands you three poorly crafted paragraphs littered with the word “significant”?

No, you don’t ask about the raise. You freak out about the paragraphs. THREE PARAGRAPHS? I’VE WRITTEN MORE IN EMAIL THIS MORNING THAN YOU JUST WASTED ON MY YEAR.

Calm yourself.

Think of this pathetic piece of paper as an opening offer — a poor offer. Your job is to transform this travesty into an accurate reflection of your year and you’re not doing this just out of a sense of self-righteousness, you’re doing to set the set the record straight.

This piece of paper is one of the only official documents of your career at this company. If you move, if your boss leaves, if there’s a reorg, this is often the first document reviewed to understand the degree of your asskickery and that means you want your boss to comprehend it.

“But Rands, I was just… so pissed. Three paragraphs? I spent my entire winter on the project. I was FURIOUS.”

Again, your review will contain surprises, and they will rattle you, which is why you prepare with a self review.

Whether your company asks for it or not, the moment the mail from HR alerts you to the review season, you start cobbling together your self review. Same buckets as above. My move is to keep a yearlong log of significant work as a task in whatever task tracking system I’m currently ignoring. Even if you haven’t been paying consistent attention, you’ll be surprised by what you can dig up in a weekend of considering your year.

Take a look at your year. How’d you do? No, really, I’m not actually reading it so you can have an honest opinion. Was it a great year or did you just think it was great? Yes, your boss’ opinion about your year is key, he does sign the checks, but it’s a key surprise reducing technique to walk into the review with an opinion. This moment of personal honesty you’re having with yourself is a big deal because that’s the foundation you’re going to stand on when the three pathetic paragraphs show up. Having a justifiable opinion regarding your year is a powerful, defensible position.

While it’s important to send the self review long before your boss writes his review, it’s more important that you have this opinion, this well-defined opinion, when sitting down to read your boss’ review. Does it document what you did? Everything? Does the description of what you did match your perception? No? Why? Don’t tell me, tell your boss, and make sure he gets it because it’s these types of historical perception mismatches that form an unhealthy basis for emerging misunderstanding and resentment.

The point of a review is the debate — to align your perceptions with those of the person who signs the checks, but even with all this structured healthy debate, there’s still going to be a…

Surprise!

I don’t know what the surprise is. It’s your review. Some of the doozies over the years from mine include:

• The total absence of recognition for a multi-month multi-team project that kicked ass.
• A reversal of opinion regarding a piece of work I’d done, usually towards the negative.
• Completely contradictory areas of improvement.

Unfortunately, the surprise is the point. A review not only forces the alignment discussion, it serves as a warning for the coming year: What do I need to do differently to avoid being blindsided when the next review arrives?

Fact is, you’re never fully going to get your boss on-board with your year. There are opinions he has which aren’t going to change, which means if you don’t want another surprise next year, you have to change.

A review’s value lies not only in the documentation of what was observed, but also what was not.

The Permanence of the Written

In many years of reviews, the only consistency I’ve noticed is that they’re getting shorter. My unsubstantiated paranoia is that lawyers apply subtle corporate pressure to retain less descriptive documentation of what actually happened in the company. But perhaps it’s just a growing professional laziness.

Whatever the reason, a brief review is just sad. If you’re staring at three useless paragraphs, you have a couple of problems. You’ve got a company that allows crappy reviews and you’ve got a boss who is unable or unwilling to articulate either the quantity or quality of work you’ve done.

That’s all sorts of screwed, but it’s only complete breakdown only occurs when you don’t react.

The first review I wrote was awful. It was three paragraphs derived from scanning status reports from the past six months. I sat in the room as she read the review and she didn’t have to say a thing for me to understand that I’d be spending the weekend actually writing the review. I got an accusing, furious glare. You didn’t even try.

So I did.

A Toxic Paradox

Everyone is an adjustment. When you’re interacting with anyone, you leave the core you and become slightly them. This is not a betrayal of who you are, this is the middle ground we define between any two people. It’s a place of compromise so we can communicate.

There are those people with whom this is an easy, natural place to reach. It’s that friend that you haven’t seen or heard from in six months, and the 12 seconds it takes for both of you to get back into a familiar place where the six months vanish. It’s the easy now.

Then there are those people who are more work. They require a protocol of context setting, translation, and cautious check-ins. Hi, I said this, is this what you heard? Ok, good. This set of abilities, of communication skills, is more work and is a skill you refine over the years. It is a requirement of seasoned managers who are constantly thrown into meetings with strangers where they need to move quickly and efficiently past the “getting to know you” phase and into the “we’ve got work to do” portion of the meeting.

My guess is the majority of our relationships fall into the either the natural or slightly-more-work buckets. The majority of the folks you surround yourself with both inside and outside of work are manageable. Not all are natural, so they are work, but you can live with them and are willing to do the work to maintain the relationships.

Then, there are those you can’t handle. These are the folks who, for reasons you may never understand, behave in a way that you’ll never grasp, can’t define, nor will ever like.

These people are toxic.

Big Fat Toxic Assumptions

This article is going to end with someone getting fired and it makes two large, uncomfortable assumptions.

First, as I explain the serious issues with toxic co-workers, I need to remind you that when it comes to disconnects between two people that there are always two vastly different stories regarding perceived toxicity. If I were to say that Veronica had a toxic personality, you would do well to spend some time with Veronica and see what her perception was of me. While I might have done as much due diligence as possible to examine every possible personality angle regarding Veronica, there would still be essential data to be gathered directly from her.

A declaration of toxicity is a judgement. Sometimes defined by a group, sometimes spearheaded by an influential individual who simply cannot find a healthy way to relate to this person, but regardless, never trust a toxicity label without doing your own research.

Second, this article isn’t about fixing the problem; this article assumes you’re done. You’re done trying to bridge the gap between you and this toxic person. If you’re a manager, this is hopefully the end result of months of careful negotiating, delicate compromise, and hardcore communication.

There are entire parts of your organization dedicated to providing ideas and skills about how to interact better with anyone on your team and this article assumes you’ve employed all of them.

I’m not going to walk you through strategies for dealing with toxic people because you’re past that. This person is infecting the team with their toxicity and you’re vastly underestimating the daily damage this person is doing to the group.

This article is here to convince you it’s time to make a change.

Go Team!

A toxic person kills, and by kills I mean totally destroys teamwork.

Teamwork is one of those painful managementese buzzwords that is blindly used at inopportune times as a means of motivation. We need better teamwork to improve efficiency and productivity. Ew. I just threw up in my mouth. Fact is, teamwork — teams of people actually working together — is kind’a magical.

Listen, it takes all I can muster to get along with my brother who I’ve known my entire life, so the fact that a group of people sitting in close proximity to each other can build a product without killing each other is a fucking miracle.

It’s not actually a miracle. It’s years of practice, starting in elementary school where you learned the basics: raise your hand when you want to speak, say ‘please’ and ‘thank you’, and don’t eat the glue. In school, you learn just as much about how to deal with different types of personalities as you do about the world, so when it comes time to jump into the workforce, you already have years of experience in social interactions with a variety of personalities.

However, all of these hand-raising, glue-free pleasantries barely prepare you for a toxic personality.

Let’s go back to the personality buckets I described above: natural, work, and toxic. Let’s say the cost of natural relationships is 1x. It’s the base unit. It’s no work, it’s simple. Let’s say that the work relationships are 2x. It requires twice as much effort on your part to bridge the communication and social gap. It’s not difficult. It’s just work. You reduce this cost as you gather more experience and as you get to know people a bit, but these relationships will never be totally natural. Fact of life.

A toxic relationship cannot be measured in terms of these work units because, at its core, it does not work. You never get to a state of comfortable communication in these relationships. They are never predictable, nor very productive, because you are in a constant state of social corrosion. There are brief moments of clarity where you have a lightning strike of insight: She’s this way because I said that and this is how she always reacts to that… so I won’t do that. Brilliant!

These moments of respite are short-lived. For reasons you may never understand, you are incapable of reverse engineering this personality, or your patterns of reaction to it, and it’s only a matter of time before you rediscover this basic disconnect and move back to thrashing around, trying to figure out the unknowable.

Yes, this is a worst case scenario.

Groups of people get along because they all subscribe to a similar culture. Yes, these people are all unique, but they get along because they have a similar belief system and buy into the same goals. This similarity of beliefs has a lot of benefit, but the biggest win is that it reduces organizational friction. There are heated arguments, but they are arguments based on similar beliefs and the presence of these beliefs means these arguments have a chance of resolution.

Now, think about your base interaction with this toxic person. You sit down in the conference room across from them and the topic at hand is easy, really cultural easy. “We’re discussing a small change to the architecture, and since you own a big part of it, I wanted to get your opinion.”

Reasonable. Professional. Respectful.

THIS ISN’T A SMALL CHANGE. YOU HAVEN’T THOUGHT THIS THROUGH. WHY WASN’T I CONSULTED EARLIER? HOW COULD WE CONSIDER THIS GIVEN WHAT I SAID 14 MONTHS AGO ON THIS VERY TOPIC WHEN I WAS IGNORED…

It’s a flood of incomprehensible toxicity. Now, inside of the flood is a bunch of historic fuck-ups on everyone’s part, but go back and read that previous paragraph. Are you seeing any of the content or are you seeing the toxicity?

Do the math. This is one meeting, and while you might pull off a meeting win when everyone’s calmed down, you’re spending the first 30 minutes of the meeting in ALL CAPS, and here’s the bad news: a majority of the team is having similar experiences. Most of the folks interacting with this person are spending their time trying to figure out how to keep this person from going ALL CAPS rather than actually getting work done.

After a time, this results in even more damage. People stop scheduling meetings with this person. They stop traveling to their part of the building and, again, I’m not talking about one or two people here, I’m talking about the majority of the team.

My definition of toxicity isn’t based on the idea that you are incapable of getting to a professional place with this person; it’s based on the idea that the culture of your group, your company, is literally rejecting this person. Everyone is avoiding this corrosive person and this avoidance is affecting productivity and morale across the board. It’s a daily emotional tax of frustration and demoralization.

A culture rarely changes for one person and in the case of a toxic person a culture will protect itself through rejection.

A Toxic Paradox

Rands, he’s just not getting along with the right people.

No.

This is not high school. I’m not talking about cliques here, I’m talking about culture. Cliques are inevitable micro-collections of people who like the look and sound of each other. Culture is the foundational broad strokes of beliefs, values, and goals in a group of people, and a healthy culture is inclusive. It seeks out new members who evolve the culture into something new and better. It’s constantly growing in interesting ways because of the people it’s built on.

A rejection by the culture, while not pleasant for anyone involved, is not a rejection based on individual taste, it’s not because someone doesn’t like someone else. It’s a rejection because of a lack of shared core beliefs. Vastly different personalities get along famously when they share a common goal.

Yes. People get petty and people dislike each other for seemingly inane, reasons, and yes, it’s a manager’s job, along with HR, to figure out how to build a constructive working relationship among these people, but this is not the situation I’m describing. I’m talking about trying to shove a toxic square peg in a cultural round hole. It doesn’t work. Keep pushing all you want, but… it’s not happening.

It’s hard to remember this when a toxic person is yelling at you, but they’re not actually yelling at you. They’re yelling at the culture. They’re pissed because their belief structure isn’t a fit with just about everyone else’s and they know it. They know that they’re not winning this argument… ever. They know that in order to win this argument, they’d need to restart the culture of the company and such an endeavor makes a re-org look like a walk in the park.

And, here’s the worst part, they might be right.

The history of the Silicon Valley is full of stories of toxic people who were, well, right. These people were physically removed from their respective companies, but their agenda, their ideas, however unpalatable to the existing cultural regime, were actually the right thing to do for that particular company.

The paradox is we often need these toxic people. We need these self-centered assholes to totally ignore cultural conventions and to mix things up beyond recognition. They don’t need social grace and they don’t need charisma. Both help, but their value lies in their intense belief in their own culture.

We need these folks, but it can’t be at the cost of the existing culture. Yes, this toxic person might have a core cultural contradictory belief that is key to the future of the business, but assess the risk. What if the cost of integrating that idea is half the team quitting because they can’t work with the idea’s toxic architect? Is that a viable solution?

No? Maybe?

The deportation of a toxic asset is a judgement call and it’s based on the fundamental idea that fitting in is easy, but real change is hard.

A Deep Breath

I admit it. I love it when the sky is falling. There is no more delicious a state of being than the imminent threat of disaster.

During these times, I’ve done great work. I’ve taken teams from “We’re fucked” to “We made it”. Yeah, we had to cancel Christmas that one time and there was that other time I didn’t leave the building for three days straight, but it was worth it because there’s no more exhilarating place to hang than the edge of chaos. We’re wired to escape danger.

There’s a reputation you get after successfully performing the diving saves. You’re “The Fixer”. You’re the one they call when hope is lost and while that’s a great merit badge to have, it’s a cover story. It’s spin. See, someone upstream from you fucked up badly. When the sky falls, it means someone somewhere underestimated the project, didn’t make a decision, or let a small miss turn into a colossal disaster, and while fixing a disaster feels great, you’re not actually fixing anything.

Management by crisis is exhilarating, but it values velocity over completeness; it sacrifices creativity for the illusion of progress.

Still, right now, the sky is falling and rather than let it fall, immediate action is necessary and my first bit of advice is that everyone takes a deep breath.

Sigh

When you see an impending crisis, your body has a distinct natural reaction. In your consideration of the crisis, you take a long, deep breath. You often don’t notice this, but if I was sitting next to you, I would hear sigh.

A sigh is associated with despair. We’re screwed. Sigh. My interpretation is different; this long, deep breath is one of preparation. Let’s break it down: Breathe in. Gathering your strength. Oh shit, how am I going to deal with this? Hold it. Hold it. Ok, breathe out. Ok, not sure what the plan is, but let’s roll.

The interesting part of the deep breath is when you hold it. Try it right now: deep breath and hold it. What are you doing when you’re holding your breath? Well, first off, you’re slowly asphyxiating, but in that moment of life-threatening tension you’re doing interesting work. It’s a subtle transformation from building tension to calm release. It can also be a deliberate moment of consideration.

You can let that breath out now.

It’s a metaphoric stretch, but it’s around the deep breath that I build my team’s communication structure. I’ll explain, but first a story.

The team at the start-up was in a design crisis. The 1.0 version of the product was out and doing well and everyone wanted to do, well, everything. Every feature was being considered. Unbridled ambition is a good problem to have for about a week. After a month, we had three different design directions in play with various levels of support. The creative rush of developing a new release was degrading to useless design meetings where different camps were building strategic fortifications rather than talking. Decisions were being made and not communicated. Confusion was replacing creativity.

In times of crisis, a few human behaviors can make everything worse:

1. In the absence of direction, people make shit up. Nature abhors a vacuum and in the absence of solid information, people generate their own information to fill that vacuum. They’re not lying, they have no ill will, they’re just trying to build a semblance of structure amongst the confusion. This is only exacerbated by the fact that…
2. Human beings provide mutual group therapy by endlessly talking about the crisis at hand. This isn’t the creation of new content; it’s just the regurgitation of the latest new. At the right time, this hallway cross-pollination is a great way to evolve an idea, but if all we’re doing is talking about the crisis, all we’re doing is scratching at the worry rather than dealing with it.
3. Lastly, everyone wants to know everything. Combine the communication vacuums and the group therapy creating a fire hose of additional questionable content and it’s not surprising that everyone on the team wants to know everything. Before I proceed, I want total disclosure. I have something unique to add and I better get a chance to do so.

It was an information communication disaster. There were brilliant ideas wandering the hallways, there were stickies with great ideas hanging from monitors, but in the confusion that was our communication structure, everyone was running around panicking and no one was taking a deep breath.

Three Meetings

Starting on a Monday, I imposed a new meeting structure. Let me first describe the meetings and then we’ll talk about the purpose. There were three types of meetings:

1:1s with my staff. Monday morning. First meeting of the week. 30 minutes for the folks who are cruising. One hour for those in crisis. The agenda is a simple deep breath:

1. What are you worried about?
2. Here’s what I’m worried about.
3. And discuss…

Staff. With air from our 1:1s still in our lungs, I have my staff meeting. Two hours, right after the 1:1s are complete. It sounds like a long meeting, but when this meeting is run well and full of the right people, it’s almost always over before you know it.

Staff is where we can continue to publicly worry, but Staff is where I want to turn the corner, where we turn inhale to exhale. Ok, we’re worried about a lot, but what are we going to do about it?

The tone and content for this meeting vary wildly by where we’re at in the development cycle. If we’re early in the cycle, we’re talking about the state of design. If it’s late in the development cycle, we’re looking at confidence in the quality.

There are three buckets of topics that I work through at my Staff and they’re increasingly slippery. We start with Operations (Where are we?), move onto Tactics (What are we going to do about that?), and, finally, Strategy (No really, what are we going to do about it?) I’ll explain each.

Operations — Where are we?

Operations topics are hard non-debatable measures. How many bugs we do we have? Where are we at with hiring? When are we moving? Any hard piece of data that we collectively need to know. No debate, no discussion, just alignment.

Tactics — What are we going to do about that?

Now we’re working. Tactics are changes, tasks, events, things we’re going to do as a team over the next week to address the worry we found in our 1:1s. Like operational topics, tactics are measurable, consumable things, but these are not topics we’re reporting on, this is where we’re taking action. We are going to scrub every bug in the next product milestone to make sure it belongs there. Jason is going to provide the new design by Thursday. By defining these tactics, you’re defining the agenda for the last meeting on my list, but we first need to talk strategy.

Strategy — No really, what are we going to do about it?

All of these well-defined tactics are great. They are real work, which, hopefully by the end of the week is going to define measurable progress. Go you. There are some organization, product, and people problems that you won’t be able to tackle in a week… or a month. Strategy involves deep changes to policy or culture. Our quality isn’t great, so we’re going to institute a code review culture. Our design is all over the place, so we’re going to define a style guide. Strategic topics during Staff are my absolute favorite because they represent the biggest opportunity for substantive change in the group. They’re also the hardest to define as well as the hardest to measure.

Worse, strategic changes are also tricky to implement during sky-is-falling situations because everyone is working to prevent the sky from actually falling - they’re intensely and correctly tactical. This doesn’t mean strategic discussions aren’t important during Staff. You might not discover a strategic change, but just having the discussion around the idea of change will give a glimmer of future hope to those who are hyperventilating.

When my Staff meeting is done, I’ve not only taken a deep breath, I’ve also begun the process of calmly exhaling… I now know what we need to do this week… This is generally where people screw up. They confuse the relief associated with the exhale with having a plan, with actual progress. You haven’t done anything yet except sit through three hours of meetings and we need one more.

Look What We Built Meeting. 4pm on Friday. This meeting exists for one reason - to measure the tactics we defined at Staff. Did we do what said we were going to do? From an agenda perspective, this meeting is a no-brainer. The list of topics and measurements were hopefully well-defined on Monday. Again, the content varies as a function of where we’re at in the development cycle, but some version of this meeting always occurs on Friday. Let’s review the design. Let’s look at the bug charts. Let’s confirm that we’ve made that big decision.

The “Look What We Built” meeting is the time to demonstrate progress, to show that even when the sky is falling, we know how to kick ass.

Invest in the Boring

It’s not just during a crisis that this calm, repetitive meeting pattern pays off. It’s always. I know you’ve been working with your favorite designer for three years. I know you believe you’re totally in each other’s heads, but this psychic confidence doesn’t mean you should ever skip your 1:1 with her even when the sky isn’t falling.

Communication in a group of people is an endless exercise in alignment. No matter how well you know your team, you can never predict where the internal dialogue of your team is going to wander. What this meeting structure does is set organization expectations:

• Everyone knows when they’re going to get their moment to speak in private.
• Everyone, whether they’re in the meetings or not, knows the system by which a lot of information moves around the building.
• Everyone knows, whether the sky is falling or not, how we’re measuring success on a weekly basis.

Equally important to these meetings’ existence is that they occur with obsessive robotic regularity. Years from now, when your team has been disbanded, I want you to look at your clock at 10:15am on Monday and think I’ve got my 1:1 with my boss in 15 minutes. This regularity is not a threat, it’s not a stick, it’s the basis for building trust in a team. I know I have a say.

And I haven’t even told you the best part yet.

All of this structure, all of this boring meeting repetition, exists to make room for something else. Whether you’re designing as an individual or a team, when you’re being creative, you need two things: an environment that encourages the random and time to live there. An obsessive meeting schedule is an investment in the boring, but by defining a specific place for the boring to exist, you’re allowing every other moment to have creative potential. You’re encouraging the random and random is how you’re going to win. Random is how you’re going to discover a path through a problem that no one else has found and that starts with breathing deeply.

A Disclosure

My management career began with a misunderstanding.

“Rands, you’re doing a great job on tools development and I’d really like you to Lead the effort.”

It sounded liked your standard professional compliment. Atta boy! Go run with it! Problem was, I didn’t hear the capital L.

Lead is what my manager had said. Not lead, but Lead. He asked poorly and without definition and specifics, but he did ask. He was subsequently baffled two months later when I said, “I don’t think I can finish this by next month, I need more time.”

Him: “Why don’t you hire another engineer?”

Me: “Wait, I can do that?”

I see three possible situations whereby you might become a manager:

1. You decide. “I believe I am going to be a better manager than engineer. I choose management.”
2. You evolve. This is what happened to me. Essentially, a series of small decisions and actions where, at the end, you end up being a manager.
3. You have no choice. “You. Manage this team. Go.”

Whether you get to choose or not, there are aspects of management that you need to understand.

Management is a total career restart. Now, if you’re evolving into the career, this will be less obvious, but if management just landed in your lap, realize that while you’re in the same game, it’s a totally new game board, and you’re at square #1. You will use the skills that made you a great engineer, but there’s an entirely new set of skills you need to acquire and refine.

This sensation will appear at the end of the day when you ask, “What did I build today?” The answer will be a troubling, “Nothing”. The days of fixing ten bugs before noon are gone. You’re no longer going to spend the bus ride home working on code; you’re going to be thinking hard about how to say something important to someone who doesn’t want to hear it. There will be drama. And there be those precious seconds when there is no one in your office wanting… something.

You go to a lot of meetings. You already knew this, but Managers Go to Meetings. Meetings are the bane of my existence and I consider it my personal goal to kill as many possible, but I still go to a lot of meetings. As best I can tell, there are two useful types of meeting: alignment and creation. Briefly:

Alignment meetings sound like this: “It’s red, are we all in agreement it’s red? Ok, swell. Wait, Phil thinks it’s blue. Phil, here are the 18 compelling reasons it’s red. Convinced? Done now?”

Creation meetings sound like this: “We need more blue. How are we going to do that? Phil, you’re our blue man. What should we do here?”

There are other meetings out there, but you will learn to avoid them. One being the therapy meeting. They sound like this: “Show of hands, who likes to talk about blue? Or red? I don’t care. Let’s explore our color feelings for the next 60 minutes.”

In time you will learn which meetings to attend, but when you start you will go to all of them because…

You are a communication hub. One of your primary jobs as a manager is to be a communication hub not only for all of those working for you, but for everyone who needs something from you. This means you are going to spend an inordinate amount of time sitting in random conference rooms and listening. Hard. Who are they? What do they need? Do I understand what they are saying? Should I say no now or let this fester?

Confusingly, as a manager, you often get credit just by showing up, sitting there, and nodding. As a career management strategy, the “nodding fly-on-the-wall” approach isn’t proactive or helpful. But there are critical times when all that is being asked of you is that you are the receiver of the rant. Simply by listening, by letting an idea be heard, you are helping.

However, you need to do more than listen. Whatever is being said in this meeting isn’t just for you; parts of it are for your team, which means you need amazing skills of…

Abstraction and Filtering. During these endless demands for your time, you do need to communicate, but if you’re relaying all the information that’s being thrown at you during the day, all you’ll do is relay. Your new job is one of abstraction, synthesis, and filtering. During that 30-minute status meeting, you need to develop the mental filter to listen for the three things you actually need to tell the team in your alignment meeting, but in a mere three minutes instead of 30.

Your thought is, “If there are only three things I need to know, why the hell are we spending 30 minutes in this meeting?” First, I relate to your frustration. Second, the three things you need to relay are different than the three things each of the other folks in this meeting needs to relay. Third, if you blow this, here’s what’s going to happen: more meetings.

See, your world has expanded, now…

You will be multi-lingual / translator. Each group in the company has a different language they speak and a different set of needs. As a manager, you need to be able to speak all the corporate dialects of those you depend on. Think of the healthy tension between Engineering and QA. Remember that flame war that went on between you and the QA guy for a week in the bug database? Engineering and QA actually speak the same language, but have different goals. As a manager, you will discover an entire company of languages and goals. For example:

• Sales cares about selling and doesn’t much care how hard it is to build.
• Marketing is passionate about brand, content, and voice and will argue endlessly for details you find to be irrelevant.
• Tech supports talks to the customer ALL DAY, but still feels no one listens to what they say.
• Admins speak many of these languages and have more power than you think.

Everyone believes their job is essential, everyone believes everyone else’s job is easy, and, confusingly, everyone is right.

These roles exist for a reason. The groups each bring something unique to the corporate organism. You can giggle and make fun of their bizarre acronyms as an individual, but as a manager you must speak their language, because once you do, you’re going to better understand what they want.

Learning new languages is tricky, especially when you’re just getting started. You’re going to spend 90 days being totally confused, and it gets worse because there’s…

Drama everywhere. Your manager calls you into her office first thing on a Monday morning. It’s clearly urgent. She sits you down and starts, “I’m, uh, making a change in the organization. Amanda is really excelling in tools development so I’ve asked her to take over Jerry’s management responsibilities. I think this will make everyone more successful.”

Wondering what happen to Jerry? Feel like you’re getting half the story? Wrong, you’re getting 1/10th of the story. People are messy and a huge part of the management gig is managing this messiness. Who knows what personal or professional issue Jerry has that is forcing this management change. It’s really none of your business. However, it is your manager’s business because the people are her job.

As an individual, you’re seeing 10% of the organizational drama your manager is seeing. I know it’s intriguing to get the full story, but again, it’s often none of your business, and it’s not your job. As a manager, you get front row seats for all of the drama in all its messy glory. This is why you have a monthly 1:1 with Human Resources. Their job is to train you how to manage the drama. This is why you need to become a great…

Context Switcher. This is your morning. Six 30-minute 1:1s starting at 9am. This day is unique in that in your 4th 1:1, your architect resigns. The guy who has been designing the heart of your application for 18 months has been poached by a start-up and had piles of money thrown at him, and it sounds like there’s no way of saving him. Sounds grim. What’s harder is that when your sky-is-falling 1:1 is done, you’ve got your next one with your QA Director who has no clue your architect resigned, and she urgently wants to talk bug database, and that’s exactly what you need to do. You need to quietly and confidently forget that you’re fucked and give this team member your full attention.

There will be a steady stream of curveballs headed in your managerial direction, each with its own unique velocity. One of your jobs is to not only deftly handle the pitch, however bizarre, but also shake it off and calmly expect an even stranger one.

There’s a reason you’ll see an inordinate amount of bizarre organizational crap as a manager. See, the individuals can handle — and should handle — the regular stuff. You want a team of people who aren’t bringing you every little thing, but if you successfully build this team, your reward is that what is ends up in your office is uniquely kooky.

As these freakish pitches whiz by, you will be judged in two very different ways. First, what did he do about the pitch? Are we going to see more of these? Second, how was his composure as that pitch whizzed by, missing his nose by an inch? Does it look like he handled it or is he freaked out and ready to bolt?

Leadership is not just about effectively getting stuff done, but demonstrating through your composure that you aren’t rattled by the freakish. Fortunately, one of the new tools you have to control the proliferation of freakishness is the ability to…

Say No. This is your second most powerful tool. Whether you’re a manager, considering management, or just here for the Rands, I want you to pick the hardest problem on your plate. The one that is waking you up at 4am. I want you to decide and to say out loud:

“No.”

You’re not going to do that thing. QA can’t test it. Engineering won’t finish it. If we attempt to do it, we will fail and we don’t fail, so the answer is “No”.

You had this tool as an individual. You could say no, but you usually did so by cornering your manager and explaining, “Here is why No is the right move here,” and then he’d say no.

As a manager, you are caretaker of No for you group. When it is time to do the right thing by stopping, it’s your job to bust out the No. You defend your team against organizational insanity with No.

No does not come without consequences. Saying No because you can rather than because it’s right slowly transforms you into a power-hungry jerk, but again, this is your new tool to do with as you see fit. Also, it’s not all No, you can also…

Say Yes. Yes is how you begin building both people and things. It’s not just a positive word; it’s the word that provides the structure for moving forward. “Yes. Begin”, “Yes, I know he’s leaving. What are we going to do?” and “Why yes, we should tackle the audacious.”

There will be times when your Yes needs to be unencumbered by reality, where it needs to be the inspiration that demonstrates how you perceive the unknowable.

“Yes, I think you’d be a fine manager.”

Trust So You Can Scale

As a new manager, whenever the sky falls, you’ll become an engineer again. You’re going to fall back on the familiar because those are the tools you know and trust, but it’s time to trust someone else: your team.

If I could give you one word, a single, brief piece of management advice, the word would be “scale”. Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing.

It’s time to translate and to teach what you’re good at to those who you work with, and that starts by trusting them to do that which you previously only asked of yourself.

The benefits of defining and maintain this trust create a satisfying productivity feedback loop. By trusting your team, you get to scale, and scaling means you hopefully get to do more of what you love. The more you do, the more you build, the more experience you gather, the more lessons you learn. The more lessons you learn, the more you understand, and that means when more shows up you’ll have even greater opportunity to scale.

The Larry Test

Larry was pissing me off.

We were a year into a two-year development process. Far enough along to have confidence that we could do it, but not far enough to be sure when we would get there.

Features were claimed to be done, but each build of the product was a study in broken and frustration.

So I’d ask Larry, “Why doesn’t this feature work?”

Larry’s lengthy answer demonstrated his deep knowledge of the product, his confidence in his team, and incontrovertible evidence that they were making progress and that the feature would work “real soon now.” Larry would convey this confidence and I’d leave the conversation swimming in a pleasant sense of managed calm, but a day would pass, I’d install the next build, and shit was still broken.

I knew if I walked into Larry’s office I’d get the same fire hose of comforting reasoning regarding why we weren’t done. I also knew if I waited another 24 hours to see another pile of broken bits, I’d lose it, so I stopped, took a deep breath, and wrote myself a short list.

Seven bullets. Each representing a feature that needed to work. Not done, just working.

I took the list into Larry’s office and handed it to him: “This is the Larry Test and you need to pass it.”

Done

This is an article about choosing to be done.

Done has a lot of definitions, depending on where you’re standing in the building. Marketing thinks you’re done the first time they see a working demo. Program managers think you’re done when the deadline arrives. QA thinks they decide when it’s done because they’ve got fancy metrics to define doneness: “No high priority bugs found in the software for a week.” Ok, fine metric, but for engineering, done happens long before all of these definitions.

The issue is that an engineer’s definition of done is the perfect set of code, and left to his own devices, an engineer will endlessly improve the code on the mythic journey to done.

It’s never done. For any large project with many personalities in play, at best it’s always good enough. Sorry.

This is not an argument for mediocrity. You can toot your horn about quality and only be good enough, but I guarantee — I promise you — that you will ship with significant piles of two types of bugs: the ones you know and the ones you don’t. Engineers have an innate sense of where those bugs are, and if you don’t tell them to stop, they will merrily continue towards their goal of total elimination of all bugs.

This is why, when the time is right, you indicate to your team you’re done, and I use the Larry Test.

Are You Larry Worthy?

The art of the Larry Test is not in its writing, it’s when you choose to use it. When are you choosing to be done?

Paradoxically, it’s the engineers who will never actually be done that I size up to figure out when to land the Larry Test. I’d like to say there was an obvious measure, a clear sign that indicated it was time to pull out the Larry Test, but it’s a culmination of little signs.

• The senior engineer who worries the most saying something small but positive.
• A strange cessation of all meetings, indicating that we’ve stopped talking about how it should work.
• Hallway conversation about the bug database.

Each engineering team is different, so each set of subtle signs will be different. In a pinch, my advice is to sit each person down and ask, “Are we done?” Their answer will usually be no, but listen carefully to the size of the no. There’s done in there.

Before You Land the Larry

Poor application of the Larry Test can exacerbate a fundamental tension between managers and employees. We all have a boss, right? Wherever you are on the organization chart, part of your manager’s job is error checking. Been in this meeting? You know, the one where you bring in the project plan for the next year? It’s taken six weeks of hard work by your team to build this comprehensive and compelling plan and what does your manager do when you begin? He starts poking holes in it. Nit picking.

Show of hands. Who likes to be told what they’ve done is flawed after six weeks of hard work? I thought so.

Different managers have different communication styles and there are those where delivery of criticism feels almost pleasant. But criticism, whether it’s constructive or destructive, coming from the guy who signs the checks often triggers the knee-jerk negative “I did something wrong” vibe.

Reactions to this criticism vary: “He’s just trying to show he has value by poking random holes in our hard work.”

No, he’s not.

What your boss has that you do not is, hopefully, more experience. What he should be able to do after looking at a situation you’ve been staring at for a month is say, “Yeah, I’ve seen this before and this is how this is going to play out.”

It’s annoying. “Why did he wait a month to say something us? We’ve been wasting our time!”

No again. Part of your job is to become your boss. What you are doing while stumbling to and fro is finding and building the experience your boss already has. The trick and the art is, how long did your boss let you stumble? I mean learn.

There’s a fine line between managerial insight and incompetence. Your job, and your manager’s, is to let your team wander long enough to find that experience.

In the case of the Larry Test, your job is to find the precise moment to tell the team it’s time to be done. Do it too early and you’re going to look out of touch. Do it too late and you’re going to be, well, late.

An Evolving Done

I wrote the original Larry Test on a yellow Post-it note. I wrote it at midnight on a Sunday night after the team had worked the entire weekend, but the bits were still all over the floor. The Larry Test was not comprehensive, nor was it even readable. It was me, in the middle of night, thinking, “What has to work?”

Your Larry Test will differ. Maybe it’s not features you need working, but performance. I don’t know what you do, so I can’t tell you what to measure, but the point is not entirely in defining the test. The point is: when are you going to stop the design and stop the development and communicate that it’s time to be done?

No one really knew about my Larry Test for a week. It was just for Larry and I, but his team figured it out. After a week of Larry repeatedly hammering, “These are the 7 things that will demonstrate that we’re serious about being done”, there was a version of the sticky stuck to the corner of everyone’s display,

This is my test and I need to pass it.

The Trickle List

There’s a gaping hole in The Taste of the Day. Yes, it’s a handy task management system, but it’s incomplete. It describes a process for constant scrubbing of a task list, as well as a handy place to keep distractions out of your way via the Parking Lot, but at the end of the day, what exactly is it helping you do?

Here are three tasks from my current list:

• Headcount Asks
• David Lunch
• Move EU Trip

These are tasks for today. They are well-defined, measurable, tactical, and they need to be done today. While it’s professionally terrific that I’m actively making sure that nothing is falling through the cracks, these are still just tasks. What am I accomplishing when I complete them? I’m getting things done.

Is that what you want to do all day? Things? Stuff?

No.

You’re a Sr. Development Engineer or an Engineering Manager or a Project Manager, and while things and stuff are part of the gig, if it’s all you’re doing, you’re productive, but you’re vigorously running in place. You’re tactical, but not strategic. Tasks are an incomplete picture of what you do and what you need to do.

The curse of any effective task management system is that you get really good at capturing, prioritizing, and executing tasks. To the point that you start to believe that merely completing a task is helping your career. After a solid decade of rampant task management, I realized I needed to augment tasks with a system that would strategically guide and remind me that my job was not to do things, but to remember the interesting words in my title: manager, engineering, and products. That’s what I do.

What I needed was a guiding force behind these tasks, a way to remind me that I was pushing towards a goal and defining and refining a strategy.

I call it a Trickle List and it looks like this:

Trickle Creation

My first excursion into the word trickle was a productivity article called Trickle Theory. The argument was simple. You can do more than you think with small, consistent investments of your time.

To understand the Trickle List, you need to first look at the headers at the top of the list. These are the heart of the list and how you define them is how you define what you want to do.

A good place to start is figuring out what your current job is. If you need a reminder, go scrub that task list again. The question I want to start the Trickle List with is: “What should your job be?”

Ok, got it? You want to be a manager. Good, we can work with that. What simple, regular tasks are going to point you in a managerial direction? Do you need to network? Do you need to file more bugs? Write more specs? Strategically, I don’t know who you work for or where you’re headed or what your company values, but here’s the good news with the Trickle List: you don’t have to be perfect. In fact, imperfection is a great place to start.

Here’s my current list:

• People — Have a random chat with someone in the hallway
• Rands — Doing something Rands related
• V — Take a vitamin
• Biz — Learn a part of the business
• Book — Reading something in a book

“Rands, these are simply recurring tasks.”

No. They’re not. You’re doing more than stuff and things with your trickles; you’re designing moments of high potential. I’ll explain.

Having a random hallway chat usually isn’t going to be a career changer. 9 out of 10 of those conversations are lightweight, but those are 9 conversations I wouldn’t have had otherwise. Plus, it’s hallway visibility, and in a gig where 90% of the days are spent holed up in meetings, that’s time well spent. And there’s the 10th conversation where I learn something huge:

Wait, the project is HOW FAR behind?

Hold it, you’re thinking about QUITTING?

By choosing to create a moment where I leave my structured day to have a random conversation, I’m creating informational opportunity, and while these moments may appear to have low initial return on time investment, you’re playing a numbers game. You’re counting on the fact that, over time, over many moments, you’re creating unexpected potential.

The items on your Trickle List don’t need to be huge, in fact, as we’ll learn in a moment, the bigger they are, the less likely you’ll do them. What they need to be is aligned with where you’re headed. However small, they need to be a daily reminder that you’re headed somewhere. The size and the impact of the trickles will come from repetition. Here’s three months:

That’s not just 90 vitamins I remember to take, it’s 47 random hallway conversations that not only increased my hallway visibility, but also resulted in the discovery of some sweet gossip, gave me a chance to deliver some quiet career advice, allowed me to unearth an impending, avoidable disaster, and, oddly, taught me a lot about high definition TVs.

The Trickle Process

With a couple of defined trickles, let’s talk about how to work them into the day. Remember the Taste of the Day process. The Morning Scrub, the creation of the Parking Lot, and finishing the day with an Evening Scrub. The Trickle List integrates with all of it.

After I’ve done the Morning Scrub and after I create my fresh, new, legal-sized Parking Lot, I pull out the Trickle List for a look at the previous day. Anything that didn’t get checked off yesterday day gets brief consideration. Any clue why it didn’t get checked? Offsite all day? That makes sense.

This is not a guilt-inducing list. I’m not beating myself up when I’m looking at unchecked items. I’m looking for data. Didn’t check anything? So I was buried, right? Haven’t checked off one item for a week? Is this a trickle I should be trying to do? Yes? Okay, why isn’t it happening? What larger thing do I need to change?

If your Trickle List becomes a Must Do List, you’re going to stop looking at it. The weight of Must Do will slowly transform into “I didn’t do it, so I suck, and I don’t want to suck, so I’m going to move my Trickle List out of my line of sight, like, say, to the trash.”

The last step of the morning is adding a fresh new line to the list, starting with today’s date, and then I put the list somewhere where I’m going to visually stumble on it during the course of the day. We’re off.

Hopefully, during brief moments of calm, I glance at the list and it gives me a motivational shove. “Now is the time to learn something about the business and I’ve got the bookmark right here.”

The Evening Scrub shenanigans, like the morning’s, involve assessment. It’s the end of the day and what’d I get done? “Hey, I haven’t done this trickle in a week? Why?” Again, the point is not guilt, it’s assessment. I want you to add and delete from your Trickle List with glee. In fact, if you’re not regularly adding new trickles to the list and removing others, I’d argue that you aren’t really using the list. What you need to do as part of your evolving career is, well, evolve. Perhaps you no longer need to focus on the hallway chats and that’s why you haven’t checked it off in a week. Fine. Remove it. Move on.

Maybe your trickles are too meaty. I keep trickles deliberately simple because tasks that take more than a few minutes to complete don’t get checked. You need trickles that you can easily do. I design trickles more for likelihood of completion, rather than perceived impact. Again, impact is going to come from repetition.

Lastly, as you can see from my Trickle List, I often use letters and glyphs as my column headers. My thought is that by giving them less definition, I make more room for me to be creative about how I complete them.

Structured Improvisation

My constant struggle with productivity and task tracking systems is a struggle with structure. My natural tendency is to build systems that track everything, and that’s a silly goal. There’s no way I’m going to keep track of and complete everything. I can look at my calendar and tell you what I think I’m going to be doing tomorrow, but the fact is, I won’t actually know what I’m going to be doing until I’m doing it.

This is why I’m particularly choosey about the structure I use in task tracking. I need just enough structure to not lose important tasks, but never structure that collapses when the sky randomly falls.

Because the sky always falls. There’s always a crisis. If two days pass and I don’t feel blind-sided, I start to worry that I’m not paying enough attention. This is my other requirement for my productivity system: it needs to encourage improvisation.

There’s a reason I’m scrubbing my task list twice a day. There’s a reason I’ve got the Trickle List taped to my white board. I want both lists front of mind all the time not only because I want to constantly seek opportunities to complete a task or tackle a trickle, but also because I want to be aware of the larger themes present in both my lists. This 360 degree awareness is going to improve my ability to improvise, and that’s where I’m really going to kick ass.

Your job is not to check off one thing on your list. It’s to cross three things off — at once. It’s to have an epiphany so big that you add a column to your Trickle List in the middle of the day — I MUST DO THAT — A LOT. The only way you’re going to come to massive strategic realizations is to have a sense of your entire task list and Trickle List in your head. I’m not talking about memorization, I’m talking about a complete feel of things you need to do and the ability to improvise odd strategic conclusions.

It’s the moment in a meeting where I see a hint of opportunity in that thing Phil said. I see the opportunity because I know I’ve got 12 Phil-related tasks and 2 trickles that, in a way I can never describe but only feel, intersect with that thing Phil just said.

Strategic holy shits only come from well-informed chaos, and you can take a stab at building a productively ephemeral perspective with the tactical information you gain from a structured task list combined with hopeful strategy provided by a slippery, healthy Trickle List.

The point of your productivity system is not to keep absolute track of your tasks. The point is to keep the important information in the front of your brain where it will improve your improvisation and inform your whims. A task tracking system gives you just enough information to calculate your chaos while reminding you to create and act on random moments of high potential.

The Taste of the Day

Think of this. You have a job where, whenever you need to, you can find the absolute truth. When someone asks you, “Phil, why is this happening?” you are 100% confident that you can figure out the precise answer.

This is the idyllic situation many engineers on the planet Earth live in, and, well, it’s just a great gig.

I exaggerate. Engineers do have blind spots, but for their work, for their specific pile of bits, they are omniscient. They’re their bits and they constructed them into their specific system where they are intimately familiar with the rules because they defined them.

Outside of my career as an engineer, I’ve been a store clerk, a butcher, a video rental clerk, a lawyer’s assistant, and a bookseller, and while it’s been over 15 years since I’ve done any of these jobs, I remember the sense of naive pointlessness: “What do I build? Well, I sell stuff, cut stuff, or type stuff. I don’t really build anything, I… do stuff.”

This made the first engineering gig a revelation. “You. We are building a database application and you own this specific part. It is entirely yours. Don’t fuck it up.”

Delicious, delicious structure. Sweet, sweet definition.

These basic and essential elements of job satisfaction are at the root of why many engineers make horrible managers. They are trained and love to be control freaks.

The New Gig

Now you have a new job. You have an office and you have a door. On your desk, there’s a timer that tracks the number of seconds that it’s just you alone in your office. Whenever someone else walks into your office, the timer magically resets to zero.

Today’s record for consecutive uninterrupted seconds is 47.

This is not a world an engineer is used to, this interrupt-driven day full of people and political calculus. This is where the reputation that your manager does nothing begins. It’s your manager who thinks it. It’s the close of the day and your manager wonders, “Did I actually do anything today except contend with a constant stream of people coming into my office?”

Try as you might, the structure and definition of your quiet engineering gig is gone. Your days of digital omniscience are over.

This is the big switch between the engineer and the manager. You are leaving the comfortable world of bits for one of bafflingly configured atoms, where you need to figure out how to trust those you work with. Where you need to train folks to make decisions for themselves, but also help them understand it’s ok to escalate for help. It’s a gig where you need to keep track of everything, constantly re-prioritize, but remain strategically limber.

And to do all of this, you need a task tracking system that allows you to strategically forget.

The Taste of the Day

This is my system. It’s a mix of my ability to be a systematic thinker with the fact that there is more to do than I can ever complete. I’ve been using some variation of it for ten years now and it’s how I run my day and my week.

It all orbits around a task system. Your first question will be: “What task tracking system do you use, Rands?” The answer is a simple: “Whatever works for you”. I’ve used a homegrown Excel system, Tasks, and I’m currently using Things, but as you’ll see, the strategic key here is not identification of the task tracking system, it’s using it — all the time.

This system is designed to create a living, breathing, manageable list of things you might actually do, and it starts with…

The Morning Scrub

The first task of the day is to set my head. What kind of day am I getting myself into? A quick glance at the calendar gives me the first hint of what to expect. Is this a quiet get-things-done day? A meeting hell day? Or a sky-is-falling day? Each day has a different taste and the Morning Scrub forces me to set my head appropriately. It gives me a rough sense of my capacity, the people I’ll meet, and what they might need. More importantly, it reminds me that Priority is Relative.

Humans suffer from bright’n’shiny complex, where we’re titillated by the new. Think of it like this: have you actually done anything with that last domain you bought? No. You had the idea for it on Tuesday morning and you got all fired up, so you bought the domain the moment you got in to work. At lunch you furiously doodled your design in your notebook, fully intending to get home and get started on the HTML/CSS, and then you got home… and watched Lost.

Take the bright’n’shiny complex and apply it to your entire group, where everyone is prioritizing their day by their particular inspiration and you’ll realize it’s shocking that we ever collectively get anything done.

By taking a deep breath and considering your entire day, I’m attempting to ditch all the bright’n’shininess and gather perspective: “What is going to matter today?” With this rough priority scale in mind, I do a complete scrub of the to-do list. Yeah, the whole thing. If you can’t get through this list in 5 uninterrupted minutes, your list is either too long or you’re bad at scrubbing. Don’t worry about that yet.

The purpose of the Morning Scrub is to land each task into one of three buckets:

1. Today. This task must be completed today.
2. Later. Not today. Later.
3. Never. Yeah, I’m never going to do this task. It’s gone. This is an important essential decision that we’ll talk about in a moment.

Initially, getting through this list is tricky because, invariably, a task will be so delectable that you’ll want to jump into immediate action. Don’t. The point of this scrub is not forward momentum; it’s complete prioritization. Any deviation from the scrub decreases the chance you’ll get through the whole list.

How many Today tasks are left when you’re done with the scrub? I don’t know because I don’t know who you are or how granular your tasks are, but I usually end up with between 10 and 20.

With the Morning Scrub complete, I create the Parking Lot. This is a blank legal size piece of paper that sits directly to the left of the keyboard. New sheet. Always legal size. Every morning.

Anyone who has sat through an offsite knows exactly what this paper is for. It’s the landing spot for any idea/task/thing that is worth remembering, but, if acted upon at the moment, will derail the productivity train. Like the Morning Scrub, the art of capturing a bright’n’shiny idea and landing it in the Parking Lot is an acquired skill. You’re going to want to move on the new, and sometimes that’s the right move, but you need to honestly and quickly answer the question, “Is moving on this new thing more important than finishing what I’m doing right now?”

Practice Productivity Minimalism

As I’ve already mentioned (and written about), this is not a piece where I’ll debate the pro/cons of various productivity tools. You get to find a tool that fits your personal quirks, but whatever that tool is, I have some brief advice how to use it relative to assessing your personal Taste of the Day:

• My task list has no hierarchical organization. I’ve used systems before that allow me to lump tasks by projects or by theme and, inevitably, I end up maintaining the structure rather than getting shit done. This pisses me off.
• I do use tags within Things, but only to track who the most important person is, if anyone, for a given task. This is a handy way to run 1:1s. “Show me all Bob-related things.”
• No priorities. Really. Again, priority is relative, and while slapping a priority on a task when you create it feels right, it’s wrong because two days from now the priority will be different. Priority is a big deal — as a manager you want to get the right stuff done at the right time, but the priority that matters is the one sitting in your head right now rather than the one you dreamed up a week ago.
• No dates. I’ve got to be pissing off productivity nerds now. I don’t track due dates, either. I fully scrub my to-do list every day, which means I’m constantly making real-time calls regarding scheduling tasks.

As an engineer, your natural inclination is to build an increasingly complex system for tracking your tasks. The risk is that the more structure you put into your list, the more you need to maintain it, and the more you maintain it, the less time you’ll have to actually get work done.

The Evening

After work, after dinner, or just before I go to sleep, I complete another scrub. The process for the Evening Scrub is slightly different.

First, I scrub the Parking Lot into the Later bucket. This is the first taste I get of how the day actually went. Lots of new tasks? Ok, what kind? With the Parking Lot scrubbed, I take a moment to size up the day. How’d I do on taste? My original read was “meeting-infested nightmare” — was I right? This is another priority leveling exercise. It doesn’t matter if I made the right call on the day; the point is to again set your head appropriately.

Finally, I scrub unfinished items in the Today bucket. For each item remaining, I ask, “Ok, why didn’t I get this done?” Very often, the answer is, “Not enough time”, so the item gets thrown back into the Later bucket, but sometimes it just gets deleted.

Your question is, “How did a task that was scrubbed into the Today bucket this morning suddenly become irrelevant?”

The efficient, version control-loving information pack rat in you is going to have a problem punting a task into oblivion. Your thought is, “Sure, it might not feel important right now, but WHAT IF!?”

Stop. Delete it. We’ve already wasted 37 seconds noodling on this semi-essential but tasteless task. Nuke it. By getting this task off your list and out of your head, we’re making space. Don’t worry, if the task is actually important, it’s going to find its way back to your Parking Lot.

This deletion is advanced management kung-fu and it’s based on insight I don’t like to give to new managers because it’s a total productivity buzz kill. The insight is: “You will never complete everything you should.”

“Rands, I can do anything!”

Of course you can.

“Don’t tell me what I can’t do!”

I’m not. What I’m telling you is that management is the art of choosing what not to do, which means you need to be ready and willing to look at the task at the end of a day and ask, “Ok, I made this urgent this morning. A day has passed and I had time, but never got to it. Does it matter?”

Priority is relative. What felt so important last Wednesday loses importance five days later when the larger context of your week, your month, and your career shows up. You need to develop a practice of strategic information shedding where you are constantly and intelligently jettisoning ideas and work.

A well maintained to-do list gives you a daily sense of professional well-being. It constructs the pleasant illusion that you have a degree of control in a world where you have no idea how tomorrow will taste. The system I’ve constructed to maintain this list is lightweight, built using the practical use of constraints, designed to sift through an endless crapload of information that passes me during the day, but it’s a system that is incomplete.

A glance at my current Parking Lot demonstrates this incompleteness. It’s a list of things I need to do. It’s a list of tactics that I need to do to keep the management engine running, but dutifully following these to-do’s isn’t management; it’s task execution. You need another list, one that represents the strategy for your team, your career, and your values.

And that one is called the Trickle List.

The Button

If you’re wondering about your next job, there are a series of Rands articles which might make the transition easier. First off, there’s A Glimpse and a Hook, which will describe how managers read your resume. Then we’ve got The Sanity Check, which will prepare you for the phone screen. And finally, there’s Ninety Days, which sketches out a plan for the first three months of your new gig.

There are two gaping holes in this series of articles. First, I’m missing a piece on your interview, and second, there’s no article about how to negotiate. I’m saving negotiation for a later piece because first you’ve got to convince a bunch of people you don’t know that they should spend the next three years with you.

An interview is an exchange of information, and the first and best way to screw up an interview is to forget is that it’s as important for you to gather information as it is to give it.

You may really need this job, and this might give you the impression that the steady flow of people who are parading through your interview room are calling the shots. And yes, if you let them, they will be, but while they need to learn about you, you need to learn about them. You need to figure out their Button.

Structure

Before you start pushing buttons, you need to gather a little data about how your interview is constructed. Is it structured or unstructured?

In a structured interview, each person interviewing you has a specific topic area: people skills, technical skills, etc. This means that each interview has a specific purpose and no two interviews that day are going to be alike. Someone has put in effort to make sure the different interviewers don’t step on each other’s toes.

The unstructured interview is a free-for-all. There’s an interview list, but no one has been given guidance about what to ask, so they wing it. With each person who walks in the door, an unstructured interview is a study in personality identification. More on this in a moment when I explain about interview creatures.

In general, the participants in structured interviews come prepared. There is a process, which occurred before you showed up. This might have involved a pre-interview meeting. They’ve read your resume and each person is likely capable of carrying the interview.

Unstructured interviewers waste the first ten minutes of the interview doing the homework they should’ve done before you arrived. It’s annoying, but, as you’ll see, it’s a great way to figure out what they are about.

As an aside, my preferred use of interview time is a structured-unstructured hybrid. While I don’t give interviewers specific topics to cover, I’ve chosen specific people because I know they gravitate towards certain professional areas such as technical aptitude or cultural fit. This structural ambiguity means interviewers can creatively adapt their questions to each person while also assuring that I get a complete professional picture of the candidate.

Understanding the structure of the interview process gives you some of your first insight into the organization, but the information doesn’t start to flow until you stare at and understand your potential future co-workers.

Interview Creatures

Structured or unstructured, each person who walks into the interview will bring a different agenda. The sooner you know what their agenda is, the sooner you’re prepared to handle your only job during this interview. You need to get them talking.

That’s right. Your goal is exactly the same as their goal, which is to learn by getting them to talk. It might strike you as a bad strategy, because if they’re talking, they’re not learning anything about you, but that is not your problem. In fact, if I get through a round of interviews and the interviewers have done most of the talking, I’m wondering if I want to work in a group where they haven’t figured out how to vet candidates.

Like meetings, there are different personalities that are going to walk into the interview, and each person has a Button. When you press this button, they’re going to be compelled to talk. Some personalities hide their buttons better than others, but most people have at least one.

Here’s a list of some common interview creatures organized by increasing difficulty of button discovery.

Pissed Off Pete

Pete’s agenda is obvious 30 seconds into the interview because he’s pissed off. This isn’t an interview; this is an opportunity for Pete to rant to a captive audience. He’s going to go through the motions by bringing in your resume and feigning interest, but all he really wants to do is gripe about “the situation”.

The Button: Ask anything. Doesn’t matter, Pete is going to twist the answer so that he can ramble some more about how screwed up “the situation” is.

Influence: Low. These interviews are normally a waste of time and there are two red flags to consider. First, who thought it was a good idea for Pete to interview you? Don’t they know he’s a one-trick rant pony? Second, why is Pete so pissed off? What kind of organization lets Pete get this tense?

Perhaps your best tactic with Pete is to spend as much time as possible understanding “the situation”. If it’s so bad that he’s going to ignore the opportunity of learning about you, a potential co-worker, maybe “the situation” is something you should understand before you consider joining the company. Even better, asking about “the situation” is a great button exploration technique in later interviews.

Chatty Patty

Yeah, Patty’s here, too. Again, this isn’t an interview. Patty loves to talk and the moment you ask anything, she’ll start and it’ll be hard to get her to stop.

The Button: Ask any question.

Influence: Like Pete, I have concerns about an organization that puts Patty on the interview schedule. Unlike Pete, Patty can be a huge source of information, so use the time well. She’ll answer any question: “Why do you love your job?”, “Who’s a jerk?”, “Why’s Pete so pissed off?”

Given that Patty is going to do most of the talking, her report on you is going to be vanilla and dull. Don’t sweat her.

The Poet

This is an advanced, artful combination of Pete and Patty. Like them, The Poet really has something he wants to tell you about, but unlike them, he’s not going to give it up unless you specifically ask him about it. He’s aware of what his job is and that’s to ask you questions.

The Button: The Poet is sneaky, but he’s still going to reveal his button via his questions. What is he asking about? Where is he repeating himself? “He’s an engineer, but he keeps asking interaction design questions. I wonder what happens if I ask him a question about interaction design?”

WHAM.

Pure Poetry. Listen hard because what’s coming out of The Poet’s mouth is important, and he’s not going to talk for long because, unlike Patty’s chattiness and Pete’s pissed-off-ed-ness, he’s not dedicated to his poetry. He’s going to turn it around quickly because he really wants to hear about your poetry.

Influence: Medium. The Poet is articulate and artful and this will not only color his opinion of you. The distinctiveness of his report will travel further in the organization than the useless vanilla crap captured by Patty and Pete.

Got’cha Greg

Halfway through the interview day, Greg is going to walk in the room and say nothing. He’s going to size you up for ten seconds and then he’s going to ask, “How… would you… test a soda machine… in the dark… submerged in strawberry jello?”

What?

Greg is on a power trip. He believes his job is to confuse you with a dazzling brainteaser. His belief is that catching you off-guard with this left field question is going to demonstrate whether or not you’re mentally nimble, but my belief is that Greg mostly just likes to see people squirm.

The Button: You’re going to need to first get past Greg’s question and my advice is to relax and have fun with it. These types of brainteasers are usually designed to demonstrate your thinking process, so think out loud and when you’re done, go on a button hunt.

This can be tricky since Greg clearly likes to be on the offensive, but I’ve found that interviewers who lead with random, huge, bizarre questions are compensating for the fact they don’t really like having a normal conversation. So. Have one.

Influence: Low to medium. Greg believes his value is high, but it’s likely the rest of his team know who you figured out with his first question. He’s a mental bully.

Slick Steve

Now we’re getting into some tricky personalities. Slick Steve is probably not a part of the engineering organization. He’s the product manager or some other Marketing denizen. This means that he doesn’t natively speak engineering, but as part of the strategic portion of the organization, he routinely talks to a lot of people, so he can wing it. He’s read this article and he knows that you’re trying to gather information. He’s a tough nut to crack.

The Button: Steve is going to completely ignore your attempts to find his button. “So Steve, what do you think the biggest challenges are for product marketing?” His response, “What do you think they are?”

Dammit.

You’ve got to fake Steve out a bit to find his button, and that means getting a little tricky. Try this: hit Steve with an esoteric engineering question you’re sure he won’t know. Remember, Steve is slick, which means he wants to maintain the calm, controlled elegance of his interview, so being unable to answer a question might trip him up. This is why you follow up with a question you’re sure he’ll be able to answer. Ask him that lame marketing challenges question again. He’ll answer it this time because he’s presently feeling ignorant, flustered, and needing to get back his feeling of control.

Like The Poet, Steve isn’t giving up his button easily, but once you’ve got him talking you have a chance to listen and see if you can find it.

Influence: Medium? Steve’s here and he’s not an engineer, which means the organization values him. He’s here to vet something. The question is: what?

Silent Bob

Bob is a button problem. Bob will sit down, ask his first question, his second question, his third, and you will learn nothing about him except that he’s silent. He’s not going to engage in witty repartee, he’s literally going to ignore your button exploration questions, and this is going to annoy you.

The Button: Don’t get rattled. In my experience, Bob is the senior technical guy on the team and his social skills just aren’t that good. He’s there to vet your technical chops and that’s it. He has no button. He’s not qualified to assess team fit and he knows this, so show him what you’ve got.

Influence: Very High. If you’re interviewing for a technical gig, this is the interview. This is the one you were losing sleep over. This is why you bought Dive into Python and read it over the weekend. No one, other than the CEO, is going to trump Bob. Good luck.

The CEO

Interviewing with The CEO is not necessarily an interview with the CEO; it’s the interview with the highest-level manager during your interview process. This is likely the hiring manager’s manager.

Where’s the Button? Simply put, you need to be prepared for some serious Jedi Mind Shit with The CEO. The feint’n’jab you used on Slick Steve isn’t going to work here. In fact, the CEO may start the whole interview with, “What questions do you have for me?”

Oh good. This is going to be easy.

Yeah, it’s not.

The Button: As you’ll see below, the influence of The CEO is extraordinarily high, and like Silent Bob, I want you to ignore your button acquisition activities with this guy. I want you to talk. I want you to sell yourself and tell great stories about your successes. Gather your organizational intelligence in other interviews; this is your opportunity to sell yourself to one of the major influencers in the organization.

Influence: Very High. The CEO is going to say that he isn’t the decision-maker. He’ll say that the hiring manager is, but it’s unlikely that if you do poorly with the CEO that the hiring manager will contradict his boss.

A Fresh Perspective

Interviews are exhausting. Baring your professional soul for multiple rounds of interviews with a bunch of strangers will wear you out and, when you’re done, you’ll be wondering, “What did they learn about me? Did I nail it? Am I a fit? Did I get the gig?” All good questions, but you should also be asking, “Do I want this job? Do I like these people? Is it a healthy organization?”

By the end of a couple of rounds of interviews, you’re going to know more about the health of the group you interviewed with than a lot of the people who interviewed you do. Freaky, isn’t it? Fact: all the different creatures you interview with are lost in the day to day of their respective jobs. The fresh perspective that you have after many hours of interviewing is unique and informative and while you still need Ninety Days to figure out what is really going on, you still have a lot of data.

… if you pushed a lot of buttons.

The Laptop Herring

I recently spoke at Yahoo! about the book, and, for this presentation, I adapted the Agenda Detection and Meeting Creatures chapters into a piece about how I assess agendas and people in the first 10 minutes of any meeting.

Early on in the presentation, I asked the audience, “What are the things you are supposed to do to make a successful meeting?” First hand: “Make sure everyone closes their laptop.” Yes. Full agreement from me. If you’re sitting in my meeting and your laptop is open, I promise, I swear — you are giving me half of your attention. Maybe less.

The Yahoos couldn’t drop the topic. In Q&A, the laptop question came up. In the post-presentation mingle it came up again. Everyone wanted to know if there was a situation where it was OK to whip out the laptop.

My answer, over and over again, is “No.”

Now, this is religion and not reality because it’s likely I’ll bring my laptop to a couple of meetings this week, but I am ultimately fucking up by doing this. Here’s why.

Laptop Tolerance

There were three different angles the Yahoos tried on me, and I have an answer for each:

“What if I’m taking notes on my laptop?”

This is how laptops got invited to the party. Pre-wireless-everywhere folks were using their laptops as note-paper. This is fine, but nowadays, are you really just taking notes? Really? It takes one lull in the conversation to get bored and starting glancing over at CNN, and in that moment I might say something you need to know and you missed it because you stopped listening. So, what are you doing in this meeting? If you’re going to ignore me, you can just as easily do it sitting in your office.

One solution to this problem is to leave the laptop in your office and bring a nice, bright sheet of white paper to the meeting. Try it. When forced, you might even find something interesting in the dull parts of the meeting.

“I’m required to go to this meeting and I have no role, so I bring my laptop to get work done.”

I have two answers to this. First, why the hell are going to this meeting if you have no role? Second, even if you don’t have a role, how do you know you don’t have a role? If you’re sitting there ignoring whatever is being said while you’re scrubbing the bug database, you have nary a clue what is being talked about.

When I’m forced to go to a meeting where I have no obvious role or responsibility, I give the meeting the benefit of the doubt and listen hard. What is going on here? Do I care? How can I help? With all the wonders of the Internet sitting on my MacBook Pro, this can be tricky, but what I’m trying to figure out is if I can add any value in the time that I’m required to sit there. If, after a few meetings, I’m certain I’m a) not going to learn anything, and b) can’t add any value, I stop going to the meeting. Consequences are forthcoming, but more on that in a moment.

“I run the meeting and they’re not respecting my laptop policy.”

Some meetings involve piles of people, and this creates a comfortable anonymity where attendees ignore the no-laptop policy and type away. My advice here is to politely remind everyone of your policy. Still a problem? Remind them again. More typing? It’s time to remove these people from the meeting.

Being a meeting jerk has consequences, but it’s those consequences you want to face because you’ve got a bigger problem than people ignoring your meeting.

The Herring

All this focus on laptops as the problem is a red herring. Whether you’re running a meeting with a rampant laptop problem or sitting in a meeting where you have no role, the actual problem is that someone doesn’t understand the value of the meeting.

No, it’s actually worse.

The problem is that everyone attending this laptop-laden clusterfuck is subconsciously hearing “Hey, in this meeting, it’s A-OK to waste people’s time.”

My question is: “When is it ever ok to waste people’s time?”

You’re on the defensive now and you’re thinking “But Rands, while I’m not actively contributing to this meeting, I am getting work done on my laptop.” No, you’re not. You’re giving the same partial attention to your laptop task that you’re giving to the meeting. You are doing two things poorly rather than one thing well.

The solution here is simple. If you’re in a meeting where you have no role such that you’re tempted to stare at your laptop: stop going. If you’re running a meeting infested with laptops and, after repeated gentle reminders about your no-laptop policy, there are still laptops: remove the laptop offenders from the meeting.

This brute force approach strikes me as being a violation of the Rands “Don’t be a prick” policy, but frequent readers know that not being a prick is always trumped by the even more important policy of “Don’t waste my time”. Besides, being a prick is going to have some interesting side effects.

Standing Meeting Momentum

Meetings become part of organizational culture. Just like any organization has a healthy layer of baffling acronyms, they also have a set of core standing meetings. Some of these meetings have been around forever and have a life of their own.

Thing is, in the five years that you’ve been working at that company, the company has (hopefully) changed. More importantly, so have the employees. So why in the world do we still have that useless product status review for everyone on Tuesdays at 4pm? I can get all the information from the wiki Frank set up.

If you have no role in a meeting and stop going, or if you remove someone from a meeting, you’re going to create a conflict with whoever believes that you (or the other someone) should be in that meeting. This is great. This is the discussion you want to have: “Frank, I’ve been to this meeting 12 times and I’ve no clue what I’m doing here. Please advise.”

Maybe Frank has some insight for you. Maybe he can explain some strategic shenanigans that will adjust your perspective so that your first reaction in this meeting isn’t to surf the popular videos on YouTube. If Frank can’t clearly explain why you need to be there — guess what — I’ve just saved you 30 minutes to an hour each week. Please consider this an early Christmas present.

A bunch of people sitting in a meeting, staring at their laptops, is a fat meeting. The people sitting at their laptops have no incentive to change a thing because they’re lost in whatever has captured their interest on their laptops. This is a lazy meeting full of people who are ignoring the most important question: “How do we figure out how to never have this meeting again?” Even worse, an organization that lets this meeting exist is a rotting organization. It’s a company where it’s slowly becoming acceptable to sit there and do nothing.

A meeting must fight to exist. It must defend its existence to its attendees who should constantly be asking “Why are we here?”

Now you understand the other thing I do in the first 10 minutes of any standing meeting: I think about how I can kill it.

The Enemy

The $150,000 mistake, your shipping schedule being off by a year, and The Really Bad Hire (aka: we’re being sued).

These are not screw-ups, these are fuck-ups. When you discover them, the air leaves your lungs, the back of your head tingles, and there’s an odd metallic taste in your mouth. Your mind goes blank except for the crisp mental picture that is your fuck-up.

This initial discovery is shocking, but what I want to talk about is secondary discovery. This is when your boss learns of the fuck-up, and you shouldn’t be worried whether there’s an odd metallic taste in his mouth, you should worry about who he’s about to turn into.

Management Transformations

Ideally, your boss is the levelheaded type and he’ll manage your fuck-up cleanly and easily using his years of experience, but fuck-ups knock people off their game and out of their comfort zone. Fuck-ups create stress and stress can mutate normally sane people into unrecognizable caricatures of themselves. Let’s talk about some of them.

The Interrogator

The Interrogator’s approach is an endless stream of questions: “When did the customer first call?”; “Who triaged the bug first?”; “What were the results?”; “How did we proceed from there?” It goes on and on.

What’s annoying about the Interrogator is that he actually only wants to ask one question — THE question — but he’s putting you through the paces to build a sense of context. This stream of questions will demonstrate the relevance of the one question. The one question is the only question that matters, and when it shows up, it’s time to start the meeting.

While you’re being grilled, I want you to remember this: The Interrogator is blowing off steam while asking the endless list of questions. This process of question and answer is laborious, but with each piece of data you convey, you have an opportunity to paint a more detailed picture of your fuck-up and increase the chance he can help.

There are Interrogators who don’t actually have one question that they’re driving towards, and these managers need managing. If you’re 27 questions into your 1-on-1 with no clear direction, it’s time to dig in your heels and ask, “Hey, Boss, what are you really trying to figure out here?”

The Prioritizer and the Scheduler

These are two tightly coupled management reactions that share so much, I’ve got to lump them together.

Meetings with both start with a complete inventory of the to-do list for your team. They want to know everything that you’re planning to do to resolve the fuck-up, and if this list doesn’t exist or isn’t complete, you might as well reschedule the meeting, because there is no other way to satisfy either the Prioritizer or the Scheduler.

With that list in hand, the Prioritizer will now put you through the agonizing process of prioritizing every single task on the list. If he’s in a really bad mood, he’s going to want to talk through your mental process of prioritization for each task. And, if he’s also the Scheduler, he’s going to want dates. For everything.

Unlike the Interrogator, there is no obvious point where you’re going to understand, “Oh, this is what he wants to know”. He wants to know everything. Your fuck-up has him freaked out and his reaction to this is to gather as much data as possible. Feels like micromanagement, right? It is. More on this in a moment.

The Randomizer

The insane version of the Prioritizer/Scheduler is the Randomizer. This is the manager who is going to swoop into the situation with good intentions, but he’s mostly going to randomize the team with his endless good intentions.

The warning signs of the Randomizer are easy to recognize — his marching orders to address the fuck-up change every couple of hours. You might not initially see this because the Randomizer is the boss. His sense of passion and urgency is intoxicating because everyone wants to get to the other side of the fuck-up. They want to succeed. After the third drastic change to the plan of action, the team is going to start scratching their heads and thinking, How is running around bumping into shit actually helping us?

You job as the minion of the Randomizer is to get back into the 1-on-1, close the door, and see if you can summon the Prioritizer. Your boss should be your strategic muse, not your tactical nightmare.

The Illuminator

The Illuminator is on the same mission as everyone we’ve already talked about, but hes subtle about it. You may not even know the Illuminator is in the room when you show up for your 1-on-1. I love the Illuminator. I love being the Illuminator.

See, you fucked up. The Illuminator isn’t going to interrogate or prioritize you for an hour; he is elegantly, calmly going to get you to realize the magnitude of the fuck up and also get you to suggest a reasonable course of action. In fact, you’ll be proud of yourself halfway through the meeting when you slap your forehead and say, “Wow, this what happened and this is what we should do!”

The transcendent Illuminator experience is when you don’t realize the Illuminator is gently mentally course correcting you and providing silent guidance. The cherry on top is, even if you do see this management manipulation, you realize, “Oh, he’s trying to help.”

The Enemy

On the opposite side of the spectrum of the Illuminator is The Enemy.

Like the Illuminator, the Enemy isn’t going to reveal his colors immediately, but unlike the Illuminator, he will not revel in silently providing guidance; he loves going on the attack. The Enemy is pissed. The Enemy is angry about your fuck-up and The Enemy believes that dragging you through that anger is a useful learning experience.

Here’s the terrifying reality regarding The Enemy: unlike all the other personalities I’ve talked about, the Enemy is not on your side. As long as your fuck-up didn’t involve breaking the law, your manager is part of your team, and even if he’s furious with you, he should always be trying to lead and trying to help.

If The Enemy shows up, your fuck-up has now doubled in size. You’ve got a fuck-up and you’ve got a manager who doesn’t believe in you. My hope is that The Enemy is a mood; it’s the peak fury of your manager’s reaction to your fuck-up, and, fingers crossed, it should fade into a calmer personality. Still, even when it does, you need to figure out why your manager doesn’t trust you when he’s freaking out?

The M Word

Yes, everyone except the Illuminator is a micromanager, and while being micromanaged sucks see, you fucked up. It’d be great if your manager remained even keeled, but we humans are a squishy, moody bunch, and how we react when a fuck-up is thrown in our laps varies by the day.

Whether you’re being interrogated, scheduled, or prioritized, you need to remember two things. First, it’s partially your job to figure out how to bring your calm, levelheaded boss back into the room. As long as you’re not dealing with The Enemy, each moody variant is looking for something and you need to deliver it. Second, as you stare at this strange person who was your boss, you need to remember that people with more experience can teach you stuff, but you might need to wait for it.

While you wait, might I suggest a healthy dose of proactive fuck-up triage? Your boss should help, but success here will be taking active an role in understanding the full scope of your fuck-up, fixing it, and making sure it never happens again.

Malcolm Events

There is a long-standing perk for working at high tech companies. If there is a nerd-relevant movie coming out, it is the obligation of management to get a sneak preview for the engineering team. An opening day morning showing works, but has significantly less morale impact than the sneak preview earlier in the week as it denies the engineering team critical bragging rights within their nerd community.

When Borland sent the engineering team to see the original Jurassic Park TWO DAYS before the opening, they created the single largest improvement in engineering morale in the history of the company. Intellectual candy and bragging rights, folks, that’s all you need to hand out.

The nerd frenzy around the movie was significant and was lead by the promise of “life-like computer animation”. So, it’s a win-win for engineers. Not only do we tap into our primal dinosaur love, but we also get to watch the first movie where dinosaurs actually show up and, by the way, using THE TOOLS WE WROTE. Ok, so Borland was writing programming languages and applications in the early 90s, but those ILM GUYS ARE JUST DOWN THE STREET. WE’RE BUDS.

Strangely, thirteen years later, the memory that has stuck with me from the movie was a quote by Jeff Goldblum’s character, Ian Malcolm. He was sitting in the Jurassic SUV, busily hitting on Laura Dern, trying to explain chaos theory to a paleobotanist, when he made a comment that burned itself into my brain.

He was demonstrating chaos theory by placing drops of water on the top of her raised hand and asking, “Which way is it going to fall?” (Smooth, really smooth, Jeff) The drops fell in a different direction each time and Malcolm attributed this to, “… the principle of tiny variations — the orientations of the hairs on your hand, the amount of blood distending in the skin, [they] never repeat, and vastly affect the outcome…”

For you nerds out there, go read about the butterfly effect. But for me, the quote encapsulates an essential part of practical software design. It’s been years since I saw the movie. In that time, the quote has mutated. It’s now “Seemingly insignificant events which are intent on screwing you in an unlikely way.” These are Malcolm Events.

We’re in a Hurry

We’re always in a hurry in the Silicon Valley. If we’re not making new stuff, we’re making stuff to help us make new stuff. Our stuff building process varies from company to company, but it usually follows a cycle that looks like:

Design: Think up new stuff to make, talk a lot, throw a lot away, talk some more
Development: Less talking, more doing. Engineers are heads down and manager’s are wondering what they’re supposed to do
Deploy: More talking, some yelling, managers are busily keeping everyone from killing each other, and then it’s suddenly… done.

We’re in the design phase right now, you and I. I’m the manager, you’re the senior engineer and we’re brainstorming our next release. We’ve each got a fuzzy picture of what we want to to do in the next release, but it’s not clear. There’s nothing that defines the picture, so we’re just throwing ideas against the wall to see what’s going to stick.

Nothing appears to be sticking until you say something off the cuff; I take the idea, riff on it, write it on the white board and WHAM… that’s The Feature. It’s the piece of work, the design, that will define your release. We know it is because we both sit there staring at the white board at The Feature knowing that this moment will define everything after it. Doesn’t happen often, savor it.

This is not a Malcolm Event. This moment is akin to a Holy Shit moment when you first understand a marvelous newtechnology. You must have these moments to have an inspired release, but this isn’t where you’re going to screw up.

Let’s keep moving.

Great, so we’ve got The Feature. Now, the frenzy begins. We can’t keep our paws off the white board because we know that in the next fifteen minutes, the rest of the features are just going to come pouring out. Now, during the frenzy, a whole pile of decisions are going to be made and while we’re valiantly going to try to capture them on our white board, we’re going to miss a few.

I want to pick one of these missed decisions. At first glance, it’s not a big decision. In fact, in the creative frenzy that is the discovery of a release, it’s a really small decision. When the meeting is over, we forget that it was made because we’re digesting the mental high imparted by this discovery of The Feature.

Problem is, this decision does matter. What you don’t know is that this decision clarifies The Feature in critical way for those who weren’t in the first meeting frenzy. By the way, THAT’S EVERYONE.

This is a Malcolm Event. And, right now, it’s a failed one.

Understanding Malcolm Events

What — whoa , whoa — wait a second Rands, we failed? We just designed a killer feature and we failed?

Yes, we did.

It’s a month later and development has begun and more folks are involved. Someone asks you a question about The Feature and the answer is the decision that was forgotten. No big deal, you answer the question and move on. A week later, you get asked the same question by a QA guy. Haven’t you already answered this question? Yeah, you did. Ok, no big deal. Here’s the answer.

Another month passes and by your count, you’ve been asked the same clarifying question ten times and you’re wondering, “Don’t people get it? Isn’t it obvious what the answer is?”

No, they don’t. They weren’t in the religious experience that was your original design meeting and, more bad news, these people who are asking the questions — they aren’t the problem. It’s the people who aren’t asking. It’s the ones who are assuming an answer to the question and not asking. They’re thinking, “Well, if it was important, someone would’ve told me or written it down, right?”

A failed Malcolm Event is when a seemingly insignificant event screws up your release in an unlikely way. In the case of this clarifying decision, it’s a poor communication tax. Everyone is wondering about this odd aspect of The Feature and in that confusion they are wasting time and they are wasting money.

The release might go swimmingly. The failed Malcolm Event might just be an annoyance where, in every meeting, someone asks THE SAME LAME QUESTION. Or maybe you’re not so lucky. Maybe the documentation folks never bother to ask a clarification question and your documentation describes your feature poorly. Even worse, maybe the developer responsible for The Feature spends a month developing to his version of reality before you install a build and figure out that people can’t read your mind.

There is a wide spectrum of cost for failed Malcolm Events, so let’s not let them fail.

Artifacts

Someone who has been reading this piece has had their hand up for most of the article. Ok, what’s your question?

“Rands, you’re talking about specifications! Functional specifications! Interaction designs, visual designs, and wireframes! Who doesn’t love wire-“

Ok, hand down.

No, this is not a piece that is going to describe the many benefits of writing stuff down and, yes, there are many benefits, but this is a heavy handed approach for building successful Malcolm Events.

Remember, we’re talking about the little stuff here. I’m not talking about the broad strokes of a release, I’m talking about the seemingly inconsequential details that are intent on screwing you. A well-written specification will document all of your details, but do you have time to write and maintain specifications? I don’t. I’m coming up on a decade and a half of working at fairly successful companies and I can count the number of useful specifications I’ve read on two hands. Really.

The issue isn’t that specifications are a bad idea, it’s that they are time-consuming and, remember, we’re in a hurry. Still, something does need to be captured because the first thing we need for a successful Malcolm Event is an artifact.

An artifact captures an essential piece of knowledge. Yes, it can be a specification or a blurb or a picture or a priority or even an owner. The key is you’ve got to know it’s essential to capture this artifact because you’ve been here before and you know that if this piece of knowledge is not well understood across the organization, you’re screwed.

I learned this the hard way during the second release of our product at the start-up. In an early brainstorming meeting, our VP of Sales spent a good hour explaining the need for better performance. We all nodded knowing that a future release we were moving to a new application server that would improve our performance issues. The problem was, no one ever told the VP “No” and, worse, when the product shipped, the performance was slightly worse. When the VP found out, he was in my office yelling for a solid thirty minutes.

In our next release, we correctly decided to hold off the application server for another six months and every single feature list I wrote had the following line, in bold, at the top of the list, “No performance increases in this release”.

Malcolm Event detection is simply the hardest part of your job because it’s the art of identifying the significantly insignificant and I’d like to provide some great advice here, but my advice is simple and unfortunate. The only way you’re learn going to identify potential Malcolm Events is by going through some horrible, horrible experiences.

Sorry.

Binders

Great, so using your past horrible experiences, you’ve captured an artifact. Let’s say it’s a semi-scribbled drawing of a brilliant UI design. Congratulations on your foresight to write something down. Now what? Where do you keep that drawing? In your Moleskin? Well, that’s fashionable and useless. An artifact stuff in your notebook is akin to not writing down at all.

Successful artifact management is the key to successful Malcolm Events and the key to successful artifact management are the three As. These are:

Availability: Your artifact matters. You already know that, but does everyone else? It needs to be sitting somewhere where anyone who cares is going to trip over it. It’s a wiki page, it’s a email sent to everyone, it’s a presentation. I don’t know what your organization communication patterns are, but you’ve got to stick your artifact in the middle of it. “Folks, this scribble is our future”. This leads us to:

Agreement: The reason you created your artifact is because you believe you’ve identified a critical piece of information where critical could mean novel, controversial, or just important. By making your artifact available to the team, you’re saying, “Pay attention to me” and this a critical juncture. This is when you consign a Malcolm Event to oblivion because you’re making it common knowledge. It sounds like I’m just describing availability again, but I’m not. I’m talking about the hallway argument that goes down when Phil reads your weekly status reports and it reads, “We’re not doing Phil’s favorite feature.”

So, you and Phil have it out. You debate pros and cons, he gives a little, you give a little, and suddenly, it’s ok. We don’t need to do Phil’s feature because we’re doing this other feature and Phil understands why.

Accuracy: This is the easiest part of the three As. As your artifact soaks through the organization, it’s going to change. Folks are going to tweak the scribble, Phil is going to request a minor change, and your artifact is going to evolve. Take the time to revise the artifact as it evolves in the hallway because you never know what minor change might set-off some random person who was fine with the first version of the artifact.

Availability, agreement, and accuracy. I call these nouns binders because they bind people to the Malcolm Event. If they see, read it, and comment on it, it becomes bound to them. It’s no longer an insignificant event, it’s common knowledge.

Success is Often Silence

A successful Malcolm Event is completely unsatisfying and here’s why: you know what failure sounds like, but success is silent. It’s when the release goes well. It’s when you don’t have to release an immediate update to your major release. A successful Malcolm Event is when you managed to predict the future and no one is going to believe you when you tell them what you did because nothing happened.

Management is the care and feeding of the invisible. You’re doing your best when it appears the least is happening. I love the thrill of the last month of a release as much as the next guy, but I suspect the reason we’re yelling at each other, working weekends, and feeling the depressing weight of compromise is because we’re surrounded by failing Malcolm Events.

The Truth Versus Spin

Muddled.

Our release was muddled. I was sitting at my desk talking to a white stone polar bear and trying to form an opinion about the release. The execs were going to ask. Soon.

“Well, QA is freaked out, but QA is always freaked out, so I’ll call that a wash. The UI guys wanted to get the bits out there so we can see what the users think and they don’t have any high priority bugs, so I’ll call that a good sign. The server guys are strangely quiet, but they never say much and they don’t have any bad bugs, either. That should be a good sign, but then why do I have this itch in the back of my brain that says I’m screwed, Mr. Polar Bear?”

The polar bear said nothing, but Frank did. Frank ran the UI group and Frank was tripping over himself happy with the release because his team hadn’t slept in a month and he knew the customers would love their work. In the absence of information, I jumped on the Frank train, ignored the itch in the back of my head, and turned into a True Believer. THIS IS GOING TO BE A GREAT RELEASE PEOPLE.

Two weeks of me singing the praises of the forthcoming release. Dancing in the hallways, getting the troops fired up, planning the launch party. Good times. Gooooood times. I wasn’t sweating it when the execs called me into the boardroom to give my release recommendation. We were ready. Frank said so and I believed Frank.

Execs: “Rands, your release recommendation?”

Rands: “Ship it baby! Then ship the team to Vegas where we are going TO PARTAAA… wait, what is Phil doing here?”

Phil was the server guy. Actually, he was THE server guy. Everyone else followed Phil’s lead because he was our Free Electron. Phil was a quiet guy who I liked, he had no political or managerial aspirations; he was just the most productive engineer I’d ever met. This made his presence in the boardroom… disturbing. I didn’t even know he knew where the board room was.

Execs: “Rands, Phil has brought the following graph. It shows how our performance degrades as the number of connections to the server increases. Looking at this graph, how many concurrent users do you think we can support with the release?”

Fuck.

Rands: “Ummmm… looks like about 50?”

Execs: “And what you would you expect average load to be?”

Rands: “Uuuuuuuuuuuuh… Phil?”

Phil: “200.”

Rands: “200.”

The release was no longer muddled and I was screwed.

Defining Spin

Ideally, Truth is an easy term to define. Truth is fact. Fact is provable data that you can count on. The sky is blue. Up is not down. 1+1 = 2. This is the part of the article where I ask all philosophy majors to take a Xanax and chill out. Yeah, I know truth is in the eye of the beholder and the sky isn’t really blue, but go with it for now.

Traditionally, the opposite of Truth is Spin. Spin is a pejorative term that comes out of Public Relations land. Spin is the deliberate selection of facts constructed to prove a specific point. For example, if there was a presidential debate where one of the candidates magically transformed into a blue whale in the middle of the debate, there would be someone from the blue whale’s camp on camera, after the debate, explaining the many benefits to America of being lead by a blue whale. They’d point out, “Are you aware of the average brain size of a blue whale? What do you think they’re doing with all that grey matter? Can you name a single war involving a blue whale?” While the rest of us would be giggling, someone, somewhere would think, “Yeah, I really want a blue whale as President… we could really use a bigger pool in the White House”.

Spin has a bad rap. I know you once sat through a sales call with a bunch of sales guys who were pitching your product and you had absolutely no idea what the hell they were talking about. But Spin can be used for good, and I want to reclaim the word. Go ahead; say it out loud right now… “Spin”. I love its onomatopoeic simplicity and, by the way, you Spin all the time.

Understanding Spin

Go fire up your mail program and find your last status report. How is it constructed? Probably a series of bullet points around “Things I did last week”, “Things I’m doing next week”, and “Things I’m worried about”. Does it represent everything you did in the last week? I’m not suggesting that you didn’t work, but is that all you did? Probably not, so what did you document in your status report? You document the stuff you were asked to document and you document stuff you just want to tell people about.

A status report is your Spin on the last week. It demonstrates how you carefully select facts from the week to portray a specific version of the truth. Are you lying because you include fact #1, but not fact #2? Maybe, but we’ll get there in a moment.

Status reports are a good test case for Spin. They’re constructed in a specific way for a specific audience. Namely, managers. The managers’ requirement for status reports is a maximum amount of data with minimum amount of investment. This is why they ask for status reports in a specific brief format. Employees look at these minimalist requirements as evidence that this is busy work. “How in the world can he discern what I’m doing in 12 bullet points?” Well, he can’t if you don’t do it well.

Your goal with your Spin is to make it simple, pure, and digestible. A status report is not where you explain the pros and cons of switching from programming language A to programming language B, it’s were you plant the seed of that idea:

“If we moved to Ruby on Rails, our productivity might double”.

A piece of good Spin moves easily from person to person with as little data loss as possible.

“Did you hear Rudy thinks using Ruby on Rails might double our productivity?”

Unfortunately, well-constructed Spin can be used for evil. When you really spin an idea, it can become easy to believe the simple Spin rather than the complex idea behind it. See, Spin is merely pointing you in a direction; it’s not direction itself. Spin-doctors, those guys and gals managing political campaigns, know this. They know that in the absence of information, Spin wins because it’s painfully easy to understand. They know how to turn a simple phrase into the perception of a campaign strategy:

• “We’re not going to cut and run.”
• “He’s the people’s governor.”
• “We’re renewing the promise of California.”

So, what’s the difference between these three bullet points and your status report? Well, how about your status report is intended to actually mean something? This leads us to our next point.

Spin not Sin

What does renewing the promise of California mean? What is the promise and how are we going to renew it? The problem here is not that it’s a vanilla, useless statement, the problem is that a lot of folks aren’t going to take the time to figure out what the Spin means. Fact is, there’s a whole page of detail about what the California Governor has to say about Renewing the Promise of California, but most folks are just going to register the spin “Renewing the Promise of California = Good” and that’s it.

I can’t help it that folks are lazy or just too busy to think for themselves, but I can tell you that Spin is art. The ability to elegantly construct complex ideas inside a few simple words is incredibly hard and those who have the ability to do it are to be admired because they are trying to make the world an understandable place.

As with any skill, there are those who sin with their Spin. They design catchy phrases that stick to anything, but mean nothing. They purposely select or omit facts to construct a delectable lie. I can’t think of good way to quantify Spin other than to say the truth is in the intent. If the person creating Spin believes their simplicity synthesis creates a sincere, factual message then I say trust them.

Regarding the Itch

Back to my muddled release. Why did I ignore the itch and create Spin based on the enthusiasm of Frank the UI guy? Simple. I wanted to believe. Incidentally, this is why you don’t trust car salesmen, but you still listen to what they say. This is why reading bullet points from a presentation is bad and this is why taking Spin at face value is stupid. Brief, high-energy ideas taste great, but if you want a meal, try the details. They’re outstanding and they’re real.

If you think for a moment that I was pissed at Phil, you haven’t been reading the weblog long. Phil, as a Free Electron, determined that the freight train that was our release was in the hands of a madman, namely me. My focused enthusiasm had built up enough Spin that he correctly assessed that the best way to make an adjustment was not convincing me, but the execs. He knew our server didn’t scale and he knew the most efficient way to broadcast that fact was via spinning the executive team.

Phil carefully constructed a graph that zeroed in on the core issue. He walked into the boardroom, put the graph on the big screen, and everyone nodded.
They were spun. The graph wasn’t the entire story regarding the release, but Phil deliberately picked the best fact to illustrate the story. Simple, sincere, and elegant Spin.

Meeting Creatures

Worst meeting ever.

It’s not that the attendee list is wrong. All the right people are there and they’re bright and they are the decision makers. It’s not that the topic is boring or poorly defined. It’s a big deal. The problem with this meeting is that it’s never going to end.

See, about a year ago, one of our senior engineers was reading our contract with our application server, he read “Supports ends in two years. We’re done. You’re on your own.” He freaked out, called a meeting, freaked out again in the meeting to make sure it was a big deal, so we agreed it was a big deal. To-do lists were generated, follow-up meetings were scheduled… it all had a pleasant “Look what we can do when the sky is falling” vibe. Love it when folks scurry with purpose.

Present day. It’s A YEAR later and we haven’t made the switch. The senior engineer who raised the red flag A YEAR ago is, surprisingly, actually in this version of the meeting although he is a shell of the engineer he was a year ago. I guarantee he’s not going to say a thing because he knows what I know…

… this is the worst meeting ever.

We knew nine months ago what we needed to do to make the transition to the new server application, but the problem is, it’s really fucking scary. It one of those “We’re not going to know half of what we need to do until we start” scenarios and starting means betting the company. Once we begin the transition there is no going back and this scares the hell out of everyone including the VP who will not make a decision.

Each month for the past twelve months, we have had the same meeting. This is the problem, these are the risks, this is what we know, this is what we don’t know. All that preliminary crap takes thirty minutes and since it’s been a month since we last heard it, everyone needs to be reminded of all the intricacies. Heads nod while I slowly dig my nails into the conference room table. We then begin the chasing our tail portion of the meeting where all the same questions are asked and answered again. This is why the senior engineer is no longer engaged. He’s tired of repeating himself.

Meetings are composed of people, but more interesting, meetings are composed of creatures. These are the roles, traits, and quirks of the people who show up in your meetings and after you’ve sat through a couple thousand, you’ll see the same creatures keep showing up. Knowing who they are can help you understand your meeting. Knowing what they can do, can save you time.

The Anchor
Slogan: “It’s all about me”

The Anchor is the big cheese. This is the person that everyone is talking to and this the person who will decide on whatever needs deciding. When this person talks, everyone in the meeting is listening.

Meetings are power struggles between those who want something and those who don’t want to give it to them. If you’re walking into a meeting and you need something, your first job is to identify this person. This person is the reason the meeting is happening and if you don’t know who they are, you’re missing essential subtext. It’s actually pretty easy. Just wait for someone to say something controversial and see who everyone looks at.

There are two major things to be wary of with your Anchor. First, make sure they know their job. For standing meetings with the usual suspects, the role is obvious, but for one-time meetings, you can’t assume The Anchor knows it’s all about them. A clear agenda which anoints The Anchor right out the gate is the best way to make sure everyone knows who the decision maker is.

Second, you’ve got to know what to do when there is no Anchor present. You’re fifteen minutes in and you know the Sr. VP who is actually going to help here is not present. Sure, there are eight other people here that sure like to talk, but the best move is a reschedule. You’re wasting time.

Laptop Larry
Slogan: “Pardon me, what?”

Larry is easy to identify. He’s got his portable in front of him. That’s him right there. If the portable isn’t somehow not enough, just look for lots of intense nodding from Larry… that’s him not listening.

Larry pisses me off. He goes to regularly scheduled meetings that he knows are going to be 75% irrelevant to him, so he brings his portable so he can work. Turns out he doesn’t work because he’s spending half his time half-listening to the meeting proceedings. Go read that last sentence again. He’s not working and he’s not really listening which means he is actually a net negative when it comes to productivity.

Ask Larry to put his portable away. I mean it. If you can’t vivaciously participate in a meeting you were invited to, you should not be there. “Rands Rands Rands… I take notes on my portable.” No, you don’t. You take notes and when I use some proper noun you don’t recognize, you surf Wikipedia. If notes must be taken, designate one person to do it, I want you asking me what the proper noun is… not consulting Wikipedia.

A useful meeting is not a speech; it’s a debate. If I’m up there flapping my lips and you disagree or don’t understand, I don’t want you to nod, I want you to yell at me.

Mr. Irrelevant
Slogan: “I’m just happy to be here”

Why is Mr. Irrelevant here? He doesn’t have anything to add, he’s just all smiles that someone took the time to include him in what must be a very important meeting. He is mostly harmless.

The problem that needs solving with regards to Mr. Irrelevant is figuring out who invited this guy to the meeting? What were they trying to do? Why is it that you’re paying Mr. Irrelevant to sit in this meeting, nod a lot, and take notes? If you uninvited him, he’s not going to be pissed, but the question is, who is going to be pissed? Why did they invite Mr. Irrelevant? Is he a mole? Is someone gathering essential information because they can’t be there?

There is a reason Mr. Irrelevant is in your meeting and you need to understand that reason before you punt him.

Chatty Patty
Slogan: “I don’t shut up”

Another easy identification. This one never shuts up. Ever.

Your main issue here is time. Chatty Patty is incapable of conveying thoughts in a concise manner which means everyone time she opens her mouth, everyone else is checking out.

Your first job is to figure out whether Chatty Patty is actually Ms. Irrelevant. Fortunately, getting her talking is no issue. Your job is figure out whether the signal to noise ratio is acceptable. Once you’ve determined if she actually needs to be there, your next job is containment and, to do that, you’ve got to play her game.

Containing Patty is a simple process of asking questions in a manner that she wants to hear them meaning with lots and lots of words. Questions for Chatty Patty must be precise so she can’t verbally wander. Rather than ask, “How is QA?”, you ask, “Patty, I’ve read your test plan, your current test results, and I understand you have a brief assessment for us regarding the quality of the product. Could you please give us a brief assessment?”

You’re going to feel silly constructing these lengthy requests, but not only are you giving Patty a well defined space to wander in, you’re also saving time for everyone in the meeting.

Warning, don’t ever ever argue with Chatty Patty in a meeting setting. Combining Patty’s natural loquaciousness with emotion is a recipe for disaster. Remember, she already doesn’t know how to end a thought. Throw some emotion in there and she might never stop.

Translator Tim
Slogan: “I know every acryonym ever. FTW!”

Tim is the first of two utility creatures. His role is simple, he speaks the language of everyone in the room. When hardware and software get together to talk about the issue, Tim is the guy who translates software acronyms into hardware acronyms. Tim is essential when you’ve got groups of folks who come from very different parts of the organization.

You need to be wary if Tim isn’t neutral with regard to the topic that he’s translating. If he’s biased, he’s translating in his favor which means if Tim is on your team, you’re in a good shape. If he’s not, you might want to go find your own Tim.

Sally Synthesizer
Slogan: “What he’s saying is…”

I love Sally because Sally’s job is to end meetings. As our second utility creature, Sally can grab the conversation, no matter how messy it might be, and derive the basic truth of what was just discussed.

In large group meetings with a diverse set of personalities, you must have a Sally in the room because she is not missing a thing that’s being said and, more importantly, she’s aware of the relative significance not only of what is being said, but also who is saying it. She knows who the Anchor is, she knows how to shut Patty up, and while it might appear that she’s just stating the obvious, she’s providing essential forward momentum to the meeting.

Like Tim, if Sally is biased in a meeting, she’s synthesizing in her favor. Also, Sallys can get drunk with power because her skill is invaluable. When she starts to think she’s an Anchor, you’ve got a problem.

Curveball Kurt
Slogan: “The sky is pancakes”

Kurt is easy to identify. You have no clue what he’s talking about.

The first order of business once you’ve identified Kurt is figuring out if he’s Mr. Irrrelevant. This can be tricky since whenever you ask him a question, you see his lips move, he’s clearly speaking English, but you have no idea what he’s trying to say. Hopefully, Translator Tim or Sally Synthesizer is in the room to help out here.

Your absolute worst situation is when your Anchor is a Curveball. It happens more than you’d think. The most likely case is combining groups on vastly different parts of the organization chart. Think of executives brainstorming with engineers. Every executive wants to think they can chum it up with anyone in the organization, but when it comes to their day to day job, they literally speak a different language. This means you’ve got Curveball Kurt on both sides of the table. This is an impossible meeting without some type of Translator and Synthesizer in the room.

The Snake
Slogan: “I’m actually the anchor. Ssssssh!”

Some Anchors like to hide. It goes like this:

Big meeting with the executives. Sally gets up, sets the agenda, asks Larry to please, for the last time, put the laptop away, and then the meeting begins. Curveball Kurt gets up and says something unintelligible. Translator Tim jumps in and translates for Kurt, but he translates to the executive in the RIGHT corner. Aha! There’s your Anchor. Pay attention to the RIGHT corner.

The meeting proceeds. Mr. Irrelevant says something funny, everyone laughs and then wonders when someone will remove this boob from the meeting. Finally, we reach the crescendo of the meeting and the decision needs to be made and all heads turn to the Anchor. We wait for a second and he says, “Snake? Your thoughts?”

The Snake is the Anchor in hiding and he’s in the LEFT corner. For someone reason, he’s got the fake Anchor out there taking the heat while he sits there taking it all in. Maybe he doesn’t like the spotlight. Maybe there is some strategic advantage to the room not knowing he’s the man, but he is. Fortunately for everyone, the Snake move only works a few times within a company before word gets out who the real Anchor is.

Back to the worst meeting ever. It’s the last one I ever attended because when I walked in, I knew what the problem was. We all thought we had an Anchor in our VP of Engineering, but, the problem is, he’s wasn’t willing to assume the Anchor role. Since we had a bet the company decision on the table, we should’ve grabbed the CEO the moment it was clear the VP couldn’t anchor the meeting.

You might think we were also missing Sally Synthesizer. Someone to capture the essence of what happened, but that was me. I was trying to move the meeting forward by capturing the major thoughts and repeating them for everyone to hear, but it was a useless task since the Anchor didn’t want his job.

Forty-five minutes after the meeting began, I did something I’d never ever done before. I walked out of a meeting where I was a key player because I simply couldn’t waste any more time on this uselessness. Stood up, walked out, and slammed the door. Yes, it’s an emotional move which is almost always a bad move in business, but near the top of my list of professional pet peeves is the following:

DO NOT WASTE MY TIME.

[11/21/06 Addendum]: I was writing a friend about this piece and here’s the line I used to describe it: “A silly article called “Meeting Creatures” where I call people names…” Something is not karmically aligned when you make fun of your own work a week after you publish it.

These names are not intended to paint a complete picture of the people they describe. They merely give you a starting point for understanding where your particular creature is coming from. In reality, Chatty Patty is also Translator Tim and sometime she’s the Anchor. In reality, people are messy.

While I’m happy to provide you a starting point for identifying troublesome creatures in your meeting, your job isn’t done there. Your job is to figure not how to alienate people by calling them names, it’s to figure out how to include them by taking time to understand what they need and doing your best to give it to them.

Secret Titles

What do you do? Seriously, on your business card there is a title. Say it out loud.

• “Senior Manager of Engineering”
• “Industrial Data Analyst”
• “Human Factors Specialist”

Is that what you actually do? Try this: think about the last four hours of your job and give yourself a title. Mine would be “Sr. Meeting Wrangler” or perhaps “Guy Who Listens”. Last week it would’ve been “White Board Operator”.

When you graduated from college, when you got your first job in your chosen profession, did you think you’d be doing this? No. Whatever you thought you’d be doing when you looked forward to being an “Associate Software Engineer” is not what you ended up doing.

You’d think this title dissonance issue would be a problem. You’d think that the fact that what you thought you’d be doing has nothing to do with what you do would turn into angst, but it turns out, as long as everyone is clear what your secret title it is… we’re cool.

This is a piece on micromanagement.

In hell, there are two rooms with the Rands name on them. Room number one is a room where you are constantly nauseated. If you want to torture me, if you want to make my life miserable, get me sick to my stomach. I will do anything, including shoving my fingers down my throat, in order to get out of a nauseated state. I would rather you shove bamboo shoots under my fingernails than spend a night in bed about to throw up.

The other room contains a single person. This is the one guy who, in my fifteen years of management, attempted to micromanage me. The walls of this room are white boards covered with to do lists and at the top of each list is a poorly drawn picture of me… crying.

In my mind, the use of micromanagement techniques has exactly one goal. You want the target of your micromanagement to leave the building screaming. There is no good micromanagement approach because WHO IN THEIR RIGHT MIND would want to spent their day managing the minutiae of SOMEONE ELSE’S job.

For those of you who haven’t been micromanaged, here’s a short list of questions to figure out where your manager stands on the management spectrum:

• When your boss asks you to do something, what level of detail does he use to describe his request?
• Does your boss ask you questions regarding the task?
• Once you’ve begun the task, how often does your boss follow up?
• Do you feel the urge to check in with your boss whenever you are faced with a decision?
• What is your boss’s reaction when you deviate from his prescribed means of making progress?

Micromanagers are managers who describe their requests in great detail, leaving little room for original thought. They devise endless checkpoints to determine that their plan is being followed which scares the individuals involved into vetting all decisions with their manager. When deviations from the plan do occur, the micromanager fucking loses it.

Can you imagine working in such a soulless environment? Can you see why this is my personal hell? It’s not just the utter lack of respect for co-workers; it’s the idea that the manager’s vision is infallible. My job as a manager is to move the group forward, but they choose the direction because THEY ARE DOING THE WORK.

I’m calming down now.

The common assessment of why someone is being micromanaged is, “Well, my manager doesn’t trust me”. That’s kind’a sort’a right, but the phrase is missing a key element. What is it that your manager doesn’t trust you to do? He doesn’t trust you to do your job because he doesn’t actually know what your secret title is. Chances are, he knows your official title, but the fundamental problem with micromanagers is that they don’t grok secret titles.

I inherited my micromanager via a re-org. My VP was leaving, and my development team was dispersed across the organization. I was dropped into this core technology group working on integration with an early version of Java. I was working for a first-time Director (uh oh) who had ten direct reports (crap) and the word in the hallway was that his project was shaky (screwed).

Our first 1-on-1 was scheduled at 9am on the first day I worked in the new group. He began with, “Rands, before you meet the team, I’d like to successfully fix 50 bugs in the code base and I’d like to be the code reviewer for each of your fixes. After that, let’s see about you and writing specifications.”

This was ten years ago, but what do you think my secret title was? Probably “Organic People Manager” or maybe “Osmosis Hallway Guy”. Anyone who regularly reads my stuff knows that my approach involves stumbling around the hallway asking people what the hell is going on. Yes, the new Director didn’t trust me, but, more importantly, he didn’t trust me to be what I’m actually good at, which is a “Osmosis Hallway Guy”.

A micromanager does not trust. That is correct, but, more importantly, they do not know. They do not have an impression… a profile of the person they are managing, so they ignore the person and focus on the tasks. This creates a terrific negative feedback loop where an employee becomes demoralized because they believe the manager doesn’t trust them, so they stop thinking and start waiting for the dim-witted, micromanaged cues from this emotionally inept manager who is waiting for… what? Hard work? Inspiration? What exactly did they do to create an environment of inspiration? The only inspired work that’s going on is the employee’s desperate search for a job where they’re going to be treated like a human being.

Yes, this pisses me off. Even hypothetically.

Fortunately for my situation, the company was crumbling around me, so the Director had his hands full poorly managing a series of layoffs. I escaped a month later for a start-up, swearing that if I ever saw this guy in a bar, I’d give him a drunken earful. I still scan the room each time I walk into a bar around Sunnyvale.

I’m going to try to save this article which turned into a rant by giving you three pieces of advice.

First, regarding new hires. Managers with new hires who are straight out of college often try micromanagement as means of molding new hires. This is a management sin. Yeah, I know they don’t know anything about anything, but there is a massive difference between teaching someone about their job and mandating their direction. If you believe that in the virgin career state that they can’t ask bright questions, you’ve forgotten what it means to learn. Think back to college, did you learn more in the lectures or in the lab with the teaching assistant? The lab, you say? Why? Simple, you can test your knowledge by asking questions.

Second, regarding Senior VPs. At some point of your career, you’re going to run into a VP of Engineering who randomly swoops into a development team and starts meddling with things. Get a pencil ready because I’m going to give you a piece of advice that I want you to write down and stick in your wallet.

All engineering managers miss building stuff.

Forget about whatever political intrigue brought this VP to your doorstep. He was a developer at some point and when he is meddling with your stuff, he is telling you, “I used to code and I miss it”. Once you’ve identified one of these repressed coding types, the solution is easy. Schedule a meeting once a week where you give him a demo. Don’t prepare for the demo, just bring whatever bits you’ve got and head over to the VPs office. Tell him, “This is what we did this week,” and this is the important part, “And what you do think?”

Yes, you’ve lost an hour a week, but these meetings don’t usually last more than a month. VPs have a full docket of stuff to do and once they’ve scratched their programming itch with your product, they’ll move on. Besides, you got some face time with the big boss. How can that hurt?

Third, and lastly, learn how to Say No. Another VP took a stab at micromanaging at a previous gig. It was a less dire situation than the first time because this guy was simply socially awkward. It took us a good two years to have a “How was your weekend?” conversation without odd pauses and stuttering.

In our first few weeks of 1-on-1, he tried some of the same moves as my first micromanager. I drove home after one of these meetings in a cold sweat. See, I loved the job which meant I had to figure out how to manage this guy. The weekend before our next meeting, I developed an early version of my communication template. When the 1-on-1 started, I didn’t give him a chance to say anything. It was 30 minutes of me listing off everything I knew about what was going on with my organization and my products and I did it in a very Rands-like people-focused tone.

I was showing this manager my secret title: “Guy who knows the people are the business”.

Deconstructing Managers (Day #6)

Ed: The last day of Deconstructing Managers week. It all started on Day #1.

What happens when they lose their shit?

Pride and panic. The two delicious ends of the management spectrum. Pride is when it’s going swimmingly. Great product release, selling well. Hired that phenomenal guy from the other group who is going to totally write us another fabulous product. More requisitions in the pipeline. Golly, I can’t imagine it going better, can you?

Getting to pride is usually the end result of a lot of work and a little luck. What you can learn from your manager in this phase is how they’ll deal with that swelling head of theirs. Do they take care of those who got them there? Do they have a plan for what’s next? All of these are interesting developments, but they don’t show you half as much as panic and there is no bigger panic than a layoff.

Your manager is not a manager until they’ve participated in a layoff. I mean it. I know he fired that one Fez and he hired a bunch of the team, but those are individual, isolated activities. He hasn’t truly represented the company until he actively participates in the constructive deconstruction of an organization. There is no more pure a panic than a layoff and you want to see who your manager will become because it’s often the first time he sees the organization is bigger than the people.

A layoff is a multi-month affair. By the time it’s been announced on the front page of CNet, it’s been bouncing around the boardroom and your bosses staff meeting for a couple of weeks. This means your boss has been staring at you for the past couple of weeks in 1:1s and ignoring everything you say because he’s trying to figure out how to layoff half of his staff. You are very interested in who he becomes during this time because that is actually the person you’ve been working for these past few years.

Once you’ve got a confirmed layoff, you need to go back to each of the questions on this list and ask them again. How is he talking to you? How is talking with the organization? What is he doing to make-up for the fact that pretty much everything stops in a company when a layoff is leaked? Is he staying politically active? Or is he checking out? All of these observations teach you about your boss and, conveniently, give you insight into whether or not you should be looking for another gig.

Panic backs a person into a corner and their only means of getting out of that corner is relying on skills that have worked for them in the past. This is how a normally friendly manager can turn into a backstabbing asshole when it comes to a layoff. See, they were an asshole before; you just weren’t there to see it. If you are lucky enough to see this behavior as well as make it through the layoff, well, you learned two things. First, this guy I work for degrades to jerk when the sky falls. Second, he values me enough to keep me around. The question remains: are you going to hang around waiting for him to be a jerk to you?

The Big Finish

When the first layoff hit Borland, I was a two years into my QA stint. I do not remember wondering what a layoff was and I don’t remember wondering if I was going to lose my job. What I remember is the Senior VP of Applications, a fellow named Rob Dickerson, who walked around the building, gathered the product team up, and then told us the straight dope about the layoff… in the hallway. This is what the layoff is about, this is who is affected, and this when it’s happening. I’d never interacted with Rob in my life and, come to think of it, I never really interacted with him again. Still, I think fondly of the guy because during a time of stress, he illuminated, he didn’t obfuscate.

A successful organization is built of layers of people that are glued together with managers. Each layer is responsible for a broad task be it engineering or QA or marketing. Between each layer is a manager whose job it is to translate from one layer to the next… in both directions. He knows what his employees want. He knows what his manager wants, and he’s able to successfully navigate when those wants differ.

The way he navigates these waters is by knowing the answer to two questions. Question #1: Where did I come from? Being able to relate to those you manage comes from intimately understanding their job. It allows you to speak their language. Question #2: Where am I going? A plan for your manager’s next big move is his incentive. It puts him in the uncomfortable position of trying to discern the murky political motivations of the major influencers of your company. It might not be a skill set he has, but he’s never going to stop trying because he knows where he wants to go. He’s got a map defined by his motivation.

Why do you care that your boss wants to be VP of Software? You care because his success is your success. If he doesn’t know that, he might be evil.

Deconstructing Managers (Day #5)

Ed: Day #5 of the Deconstructing Managers week. Day #1 is where this whole piece begins.

Back at Netscape, Internet Explorer was threatening, but we were under the illusion the sky was not falling. We were merrily planning the next release of the browser under the assumption that Microsoft was going to somehow screw-up their browser. Besides, it wasn’t about the browser anymore, it was about owning the entire desktop. Yes, someone was actually suggesting the browser wasn’t an application, it was an OPERATING SYSTEM PEOPLE. The perception of unlimited money makes people stunningly stupid, by the way. Anyhow, of course, everyone at Netscape wanted to the be on the “next generation browser” project. We were just waiting for the execs to crown a director to run the effort.

When the promotion came and it was some engineering manager from an acquired company we’d never heard of, heads were scratched. Until that time, the core engineering team at Netscape was a private club. We’d expected one of our long time proven managers to the lead the effort. Nope, Mike the New Guy got it and, in a week, he went from no name to the hottest ticket on Middlefield Road.

What happened? Well, turns out the engineering managers were playing a lot of roller hockey and, while they played, Mike the New Guy was working it. He was chatting it up with the execs, getting to know the relevant players, pawns, and Free Electrons in the organization… Mike the New Guy was hungry… he was driven.. and after six months of incessantly demonstrating this hunger, the execs gave him the keys to executive wash room. Mike the New Guy was a made guy.

Just like delegation, the act of navigating politics in an organization is slippery. The difference between a manager who knows what’s going on in an organization and one who is a purely politically driven slimeball is thin. I would take either of those over some passive manager who lets the organization happen to him. Politically active managers are informed managers. They know when change is afoot and they know what action to take to best represent their organization in that change.

Of all the questions in this piece, understanding your manager’s place in the political food-chain is the trickiest because you’re often not in the meetings where he is interacting with his superiors. Those are the situations where you understand what their view is of him and; therefore, his organization. The next best gauge of your manger’s political clout is cross-functional meetings where his peers are present. How are they treating him? Is it a familiar conversation or are they getting to know him? Should they know him? If it’s his meeting, is he driving it? If it’s not his meeting, can he actively contribute?

The organization’s view of your manager is their view of you. I’m glad you’re a C++ rockstar, but the problem is, your manager is a passive non-communicator who doesn’t take the time to grok the political intrigue that is created by any large group of people. I see him as a non-factor and you’re living in the shadow of a non-factor.

Sorry.

Next: What to do when your manager loses his shit and the big finish.

Deconstructing Managers (Day #4)

Ed: Day #4 of the Deconstructing Managers week. Day #1 sets the stage and is a good place to begin.

How does your manager talk to you?

My first piece of advice to all new managers is “Schedule 1:1s, keep them on the same day and time, never cancel them.” With this mind, some of the trickiest transitions for me during the day is when these 1:1s show up. I’m deep in some problem, writing a specification, answering a critical email, and this person walks in my office and they want to talk about I don’t know what… WORKING IN THE ZONE HERE PEOPLE. In the brief second I try to figure out some way to reschedule this meeting, I remind myself of a simple rule, “You will always learn something in your 1:1.”

When is your manager giving you a chance to tell him what’s in your brain? I’m worried if your answer isn’t “At a 1:1”, but I’m not panicking, yet. Maybe your manager is one of these organic types who likes to jump you in the hallway and gather relevant bits. Terrific. Does he do it consistently or when he needs something? The former is great, the latter is a problem waiting to happen.

What is a manager learning in a 1:1? Much of what you’re talking about in a 1:1 your manager already knows. You’re concerned about the reorg, right? Well, everyone is and he’s already talked to four other people about their concerns. You think the field engineers are a bunch of twits? So does he. A good manager has his finger of the pulse of their organization and the 1:1 usually echos much of that pulse, so why is he carving out 30 minutes for every person on his team?

He wants to learn.

Whether it’s a 1:1 or a random hallway conversation, your manager should always be in active information acquisition. He should love it when you stop him in the hallway and tell him, “I hate your favorite feature”. See, the thing was, he’s been losing sleep over that feature for the past three days and he can’t figure out why. Your random (hopefully justified) hatred just shoved his thinking in another direction.

Managers who don’t have a plan to regularly talk to everyone on their team are deluded. They believe they are going to learn what is going on in their group through some magical organizational osmosis and they won’t. Ideas will not be discovered, talent will be ignored, and the team will slowly begin to believe what they think does not matter… and the team is the company.

How much action per decision?

When the new VP showed up for his first day at the start-up he was wearing a Members Only jacket. Sky blue. I didn’t know they still made these throw-backs to the 80s. A jacket which lived under the tagline, “When you put it on, something happens.” I’d given the VP a thumbs up during the button-up and tie phase of the interview, so I gave him the benefit of the doubt.

Three months in, we had a problem. Members Only was doing a phenomenal job of discussing and dissecting the problems facing engineering. We’d leave meetings fresh with new ideas and promises of improvements, but then nothing would happen. Ok, so follow-up meeting. WOW! He gets it. I’m fired up, again. Let’s roll. Ummm, two more weeks and nothing is happening here.

Now, me being the Director of Engineering, you can argue that the onus of action was on me. Problem was, I was doing everything I signed up to do. The VP wasn’t. He wasn’t talking with the CEO about our new plans. He wasn’t handling the other Director who was totally checked out. When the third follow-up meeting was scheduled, the VP again demonstrated his solid problem solving skills, but I wasn’t listening anymore. I was waiting to when we got the the next steps portion of the conversation where I’d pull up the meeting notes from the previous two meetings and carefully point out these were the same next steps as THE LAST TWO MEETINGS.

The act of delegation is a slippery slope for managers. Yes, you want to figure out how not be a bottleneck in your organization and, yes, you want to figure out how to scale, but you also want to continue to get your hands dirty. Members Only’s problem was he believed his job was purely strategic. Think big thoughts; delegate the results of those thoughts to the minions. He was a pure delegator and he’d forgotten how to do real work.

Pure delegators are slowly becoming irrelevant to their organization. The folks who work for pure delegators don’t rely on him for their work because they know they can’t depend on him for action. This slowly pushes your manager out of the loop and, consequently, his information about what is going on in his organization becomes stale. Then, the CEO walks into your bossses office and asks, “How’s it going?” The third time your boss gives the same generic answer, the CEO goes to you and asks the same question. When you respond with, “Well, we’re fucked”, the CEO has an entire other conversation with your manager.

Real work does not mean that I think engineering managers need to continue to code. Real work is visible action managers take to support their particular vision for their organization. The question you need to answer for your manager is simple: Does he do what he says he’s going to do? Does he make something happen?

Next: Your manager’s political value matters.

Deconstructing Managers (Day #3)

Ed: Day #3 of the Deconstructing Managers week. If you haven’t a clue what is going, I’d suggest starting with Day #1.

How are they compensating for their blind spots?

Now we’re going to pick on your favorite manager. Tell me about him. Probably a great communicator, funny guy, charismatic, you say? He probably inspired you. You can probably quote a few of his more infamous sayings. “Better is the enemy of done.” The question is, what were his blind spots?

Each manager, good or bad, is going to have a glaring deficiency. Maybe he did escape from QA and now he’s the Director of Engineering. Perhaps he’s a stunning technologist with absolutely no sense of humor. The question is, does he recognize they have a blind spot?

I ask the same question in every interview I have: “Where do you need help?” Whether it’s an individual contributor, a manager, or my new boss, I’m always curious where a person sees their weaknesses. A flippant “I’m solid across the board” response is a terrifying red flag. I’m a fan of pride; I want you to sell yourself in a interview, but if you suggest that you’re flawless, all I’m thinking is that your flaws are so big that you can’t talk about them or you have no clue what they are.

A manager’s job is to take what skills they have, the ones that got them promoted, and figure out how to make them scale. They do this by building a team that accentuates their strengths and, more importantly, reinforces where they are weak. Dry technologists need team members who are phenomenal communicators, folks who can tell a joke and socially glue the organization together. Those vision guys with zero technology chops need you, the strong technologist, to tell them what is technically possible.

A manager’s job is to transform their glaring deficiency into a strength by finding the best person to fill it and trusting him to do the job.

Does your manager speak the language?

Ok, so, you’re in a square room. There are two clear windows in this room, one on each side. In front of each window is a microphone which, when turned on, pipes whatever you say to whomever is on the other side of the window. Now, your manager is on the other side of one window and your best work friend is behind the other. It’s Friday and I want you to give your weekly status report to your friend. Something like:

“Monday was a disaster. I got in late because I whooped it on Sunday night. Took a stab at the spec… but left a little early because I was hung over. Tuesday and Wednesday were pretty good. Finished the spec, closed some bugs, went to the cross-functional review, got some good feedback. You should read the current version. Thursday was meeting hell. Got nothing done. Three useless hours. Friday, well, I had a beer at lunch and I’m leaving early.”

Now, spin around and give your status to your boss.

I do not care if you work for the worlds best manager. I do not care if he was the best man in your wedding. You are going to give a vastly different sequence of events because you are not talking to a person when you talk with your manager; you are talking to the organization. You instinctively know that telling your boss that you had a beer at lunch is a bad idea, not because he’d know it, because the organization would.

The language you are speaking when you talk to your manager is a flavor of managementese. Yeah, the language that Scott Adams has made millions of dollars exploiting. It is a carefully constructed language which is designed to convey information across the organization. Managementese allows managers from very different parts of the organization to communicate even though their respective jobs are chock full of different acronyms and proper names. And yeah, managementese sounds funny.

An example:

“Our key objective for this project is the schedule. We need to keep our teams focused on the respective goals, but also keep them cross-pollinating so they can error correct on their own.”

When you hear that, you think, “Why can’t he talk like a human?” He’s not talking to you. He’s talking to other managers and he’s saying some very Rands-like-things like, “Commitments matter!” and “The team is smarter than the individual!” It’d be great if managers could speak with a little more art, but the job at hand is to spread information across the organization as efficiently as possible. And a local dialect of managementese is the best way.

Besides, they still need to talk you, which leads us to…

Next: Measuring hot air, relevance, and non-factors.

Deconstructing Managers (Day #2)

Ed: This is Day #2 of the Deconstructing Manager’s piece. Day #1 might help you figure out what is going on here.

I am not going to explain what your manager does all day. Sorry.

I am going to hand you six critical questions that you need to answer in order to figure out if this guy is capable of looking out for #1 — you. Ideally, you’d be able to get answers to these questions before you took a new job, but you didn’t and now you’re working for a manager who isn’t speaking your language. These questions might give you insight into where he’s coming from.

Where does your manager come from?

I’m going to start and finish here because the pedigree of your manager determines not only how you should communicate, but also what to expect when the shit hits the fan.

Ironically, the second most common complaint from the Managers Are Not Evil entry was, “My manager has no idea what I do.”It’s good to know the problem goes both ways, no? There are a couple of possible causes for this situation. Your manager may not care what you are doing. It doesn’t mean the work you are doing is good or bad, it’s just not on his radar. Some folks find this arrangement of ignorance to be a cozy warm blanket. It’s a no fuss job. No awkward hallway conversation, just me and my code and… I’m what? I’m fired? Holy shit. Well, that’s the risk of having a covert job. No one knows your value which puts you first in line when it’s time to trim the workforce.

Another likely situation is that your manager doesn’t actually understand what you’re doing because he was never an engineer. I’m not talking about the prequalified disasters where some brainiac on senior staff decided it was a good idea to put the head of marketing in charge of engineering, I’m talking about the engineering managers who are hiding the fact they never really did much coding. Sure, they can talk the talk and they’re buzzword compliant, but what was their last programming assignment? What piece of code are they really proud of? Is their degree in computer science?

If you’re getting vague answers full of words that sound right, my guess is you’ve got a faker on your hands. I’m talking about someone has managed to wedge their way into position of engineering leadership on their chutzpuh and not their technical ability. You’re not automatically screwed in this scenario. A person who can convince the organization they’ve got leadership ability and hide the fact they haven’t a clue what a pointer is… has, well, moxie.

This person has spent their entire career wondering, “When are they going to figure me out?” This paranoia has give them solid information detection skills which can be useful to you and your organization. They know when the layoff is coming, they know how to talk to senior management, but they don’t know how to talk to you because you’re actively, passionately doing something they’re clueless about and they believe they have to maintain the appearance they know what they’re doing.

If this is your manager and you believe there is value in what they do, your job is to figure out how to speak their language. Maybe they snuck out of QA? Ok, then speak QA. Maybe they just never got around to that computer science degree? Ok, take the time to teach them about your work. I’m not talking teaching this guy C++, I’m talking 15 minutes at the whiteboard with flowcharts. THIS IS WHAT I DO and this is WHY IT MATTERS.

Your manager is your face to the rest of the organization. Right this second, someone you don’t know is saying something great about you because you took five minutes to pitch your boss on your work. Your manager did that. You gave him something to say.

Next: Figuring out manager flaws and speaking managementese.

Deconstructing Managers (Day #1)

Ed: This piece is long. Really long. Like 16 pages long. For the original publishing, I’ll be serializing this piece into six days of management deconstruction. Enjoy.

Back in February, I asked the question “Who is the worst person you worked for?” If you print out the responses in a smallish font, you end up with 27 pages full of some of the worst possible management situations. I’ve read those 27 pages several times and it’s now time to turn the tables and get inside the heads of these horrible managers to figure out what makes them tick.

Before I start, I’ve got one ground rule. You can’t be actively hating your manager when you read this. If you completely despise your manager right now, this article isn’t going to help you because you have lost your objectivity. If you’re halfway through this piece, yelling at your screen that RANDS YOU DON’T UNDERSTAND, HE TOTALLY SCREWED ME, I would suggest a couple walks around building before you finish with this article. A level head is required before we proceed.

There is evil

My background. I’ve worked at six different companies in the past 15 years. In those years, I’ve had 10 different jobs ranging from QA engineer to Director of Engineering. Similarly, I’ve worked for a variety managers from first line managers to CEOs. I’ve never worked outside of engineering, but, especially in the senior management roles, I’ve been exposed to the inner workings of the vastly different functional groups that make up a company.

I’ve seen a lot of varieties of organizational pride and panic. At both Borland and Netscape, I experienced the company vibe as it shifted from “We’re the Microsoft killer!” to “We’re screwed!”. At the start-up, I showed up as employee number 20 and it watched it grow to 250 employees before the Internet bust eroded the company to 50 folks wondering what to do with all the extra hardware.

These drastic shifts in organization perceptions showed me managers who were great at the pride part, but turned into jerks when the panic started. Likewise, new leaders and lessons showed up during the panic. Leaders who were quietly getting their work done during the pride.

In all of this, I can count the number of truly evil people I worked with on one hand. There are evil managers out there. I apologize, I lied. These are genuinely evil and mean people. There are less than you think, but they are out there and my only advice is, upon detection, to run away as quickly as possible.

Your Manager’s Job

A key frustration from the Managers Are Not Evil piece is the easiest to explain. You are frustrated because you’re busting your ass, but each time you walk by your boss’s offices he’s got his feet kicked up on the table, coffee in one hand, the other hand jumping hither’n’fro, and he’s talking to some guy you don’t know. How in the world could this be work?

Here’s the deal: Your manager’s job is not your job.

Ever had a meeting with a completely different part of your company? Maybe it’s engineering and facilities and you’re talking about getting additional space for your team. Your goal is clear, “I need more space”, but once the meeting kicks off, you realize that you and facilities are speaking a different language. It’s English, but the context is wildly different. Those facilities guys are rambling about lease agreements, safety codes, and scads of unfamiliar acronyms. In five minutes, it’s clear that you have no idea what they really do.

Before that meeting, if I asked you what the role of facilities was in your company, you would’ve scrunched your face and mumbled something about cube construction. I trust that, like me, you’re an optimist and you believe that everyone in your company is busily working on whatever they do. I also believe the fact that you don’t understand what they do automatically biases you. You believe that because you understand your job intimately, it is more important than anyone else’s.

In your head, you are king. It’s clear what you do; it’s clear what is expected of you. There is no person who rules you better than yourself because you know exactly what you’re about. Anyone outside of your head is a mystery because they are not you. In a social situation, it’s entertaining to figure out what another person is about, but in an employee/manager situation, there’s more at stake. Who is this guy who decides whether or not I get a raise? What’s he saying to my VP about me? Does he see me as a success or a failure? Who is that guy in his office anyway? WHAT DOES HE DO ALL DAY?

Next: Your manager wasn’t always a manager. Plus, Rands lies.

Managers Are Not Evil, Pt. 1

“What, exactly, do you do?”

Slack.

Jawed.

Amazement.

This question is coming from someone I trust. A trusted employee who has been working in my group at the start-up for years. This guy always tells me the straight dope and now he’s asking me what I do with my day because he honestly does not know.

Let’s recap my day. I got to work just after 8am. After my usual thirty minutes of scrubbing and answering email, I did a quick check of tech news… taking a quick pulse of the planet… and then it’s off to my first meeting. It’s my bosses staff and it runs for almost two hours as usual. After that meeting, I spend 30 minutes digesting notes from that meeting into actual tasks for myself and the team while also tidying the corporate news I received for my staff meeting.

Lunch. I’m eating with the web applications team today. It’s thirty plus minutes and then I’m back for bug database scrubbing… a daily thirty minute task before a cross-functional meeting that turned ugly… needed someone to do something and they are incapable of doing it and that means I’m screwed. After that sixty minute debacle, I’ve got an hour and half of one-on-ones. It’s during this time that I am asked the lamest question ever,

“What, exactly, do you do?”

My first reaction to this question is the wrong one. I want to leap over the table, grab my friend by the shoulders, shake him, and yell, “WHILE YOU WERE USELESSLY STARING AT THAT ONE BUG THIS MORNING I WAS KEEPING THIS ORGANIZATION MOVING PAL.” My second reaction is to take a deep breath, so I do.

This basic “what-do-you-do” disconnect between employee and managers is at the heart of why folks don’t trust their managers or find them to be evil. I’ll explain why in great detail in my next piece, but first, I want more content.

Today’s question is, who is the worst person you worked for? And why? I’m looking for sour grapes, I’m looking for irrational rants, I want to hear about that manager experience that STILL MAKES YOU YELL.

Like the Remotely piece, I’m hoping the comments are far more interesting than the question.

Reinventing the Hallway

Tony passes me the hallway at lunch, basketball in hand, and the conversation goes like this:

Me: “Hey Tony, how was basketball?”

Tony: “It’s good. I was playing with Phil and he mentioned his team was working on Gimbleflibbits.”

Me: “Gimbleflibbits? That sounds a whole lot like our effort on Trimbleflibbits. Did you mention we were working on it?”

Tony: “No, I thought we were keeping it on the down low.”

What to do? I call Phil and we have a have Flibbit heart-to-heart and I learn, yes, he’s working on the exact same project and he’s fully staffed and four months ahead of me.

Well, crap. I was kind’a looking forward to nailing Gimbleflibbits, but Phil’s on the ball and he’ll pull it off, so I sit the the team down and finding a different direction.

What happened in that hallway was this. I would’ve spent five engineer’s time over six weeks working on my particular Flibbit implementation before word got to me through regular communication channels that Phil was far ahead. If you assume a base salary of $100k for these engineers… that’s about $75k just in salary that I might have wasted on a project that someone else was already doing.

I’ll simplify. I saved the company $75k randomly bumping into Tony in the hallway.

The Organic in me is just fine with this. The Organic in me knows that most interesting developments in a company happen because someone ran into someone else and said the right thing at the right time. Mechanics hate this idea and they’re constantly running around redefining process to make sure that, somehow, my Tony conversation occurs according to some master plan, but that’s not happening… people are messy.

As I said in Remotely, the absence of the hallway conversation is my single biggest problem with remote employees, but we’re in the process of reinventing the hallway for both remote and local employees…

SKEF wrote: “I think the secret here, which almost no one ever tries, is to switch completely to forms of communication that work remotely for a while (a month or two) and from then on have days where you do that.”

The idea has merit. Instant messaging has replaced a lot of email conversation in my past two companies, but I’m certain there is a small percentage of folks who get it, but haven’t tried it. A new communication media day seems like just the thing to force folks to try something new whether it’s IM or Wiki or Skype.

ERIK SCRAFFORD wrote: “… everyone must be on IM all the time in office and out.”

The myth of the 8 hour work day is fading. Yes, I tend to work 8-10 hours a day, but I also spend 30 minutes in the morning and probably another hour in the evening doing things which can only be called work. Why am I not freaking out about 11 hour work days? Well, first, I like what I do, but, more importantly, my constant presence on IM allows me to always be available to co-workers and friends when they need something from me. It’s like this:

Winston @ 10:50Pm: “Rands, did you see the crash bug fix?”

Me: “Why are you working @ 11pm?”

Winston: “Couldn’t sleep and wanted to knock off a couple of bugs.”

In a non-24/7 IM world, Winston would’ve had to wait another 12 hours before he got a response me. Multiply that experience by each of the 200+ people on my buddy list and you’re talking about productivity no longer bound by the imaginary 8 hour work day.

For remote folks, my opinion is it’s their burden to make themselves readily visible in as many mediums as possible because, well, they’re not visible.

MARTIJN DEKKERS wrote: “The off-site worker should have very clearly defined and well structured work to do that requires minimal interaction with other team members”

DAN also wrote: “Either give remote employees standalone components, and make sure the interface is well defined.”

Giving remote folks clearly defined, standalone components that requires minimal interaction with the local team reduces risk that a local (or remote) person is going to be stalled because of remote communication latency. This makes sense. I get this. Problem is, this approach only furthers the distance between the local and remote folks. It strikes me that you want to give remote folks a project that will force them into communication habits that keeps them in touch with the team.

DAN follows up his comments by suggesting, “Or, pair remote people up with some else and make them work together very closely.”

This seems like a more productive practice. It’s going to be harder for local and remote folks to communicate, but if I got remote folks, that’s what I want them working on… improving communication.

DAVID GOODLAD wrote: “I’d worked with the company for about a year before I moved out of town, and the team’s pretty stable, so I know everyone that I work with very well.

MARTIJN DEKKERS also wrote: “[schedule] frequent back-to-base meetings”

To me, this the strongest piece of advice out there. Make sure your remote folks know the rest of team. Yeah, we got phone, mail, IM, skype, wiki, blah blah blah, but nothing replaces sitting around the table and understanding who is on your team by seeing their faces.

I’ve been trying video conferencing with one of my remote employees and I’m getting over the fact that I’m talking to my monitor, but I still feel the miniscule awkward lags in the conversation that occur because of the technology. This jumpiness makes our conversations feel slightly artificial, but it’s ok, I worked with the guy for months before he left, so I can fill in the gaps.

TREBORINATO wrote: “The team’s perception of the matter is vital, and they may not be easy to reveal how they really think about the situation.”

I hadn’t even thought of this problem until I read it and realize it’s severity. Many local folks are jealous of the remote employee because of the perception the remote folks are privileged. “How come Phil gets to work at home in his underwear?”

At my prior gig, there was an active subconscious effort to discredit the remote employees and it was based on the fact the local folks had no clue what the remote folks were doing. They assumed they’re weren’t doing anything (wrong), grew bitter about it (bad), and stopped collaborating with the romote folks because of spite (screwed).

In this case, I think the burden of communication is on the manager to keep their local folks aware of the contributions of remote folks. Meanwhile, remote folks need to operate knowing their local folks are fretting about underwear work days.

BEAR wrote: “What I’ve seen in the past is that the reasons that remote people fail is not because of the technology - heck, I was doing remote work back in the days of 9600 baud modems, but rather because of the process (or lack of.)”

… and that’s the point. The hallway conversation occurs because folks happen to bump into each other. There’s no HR guideline which says, “Randomly walk around the building until you bump into someone interesting”. It just happens. The way to create that chance productive hallway meeting has little to do with the technology you spread all over the team, it has to do with keeping those remote folks in the front of your mind rather than that guy out in bumfuck who appears to be doing his own thing.

Remotely

Anyone who’s worked with me has stumbled on my policy on remote employees. The short answer is, “No”. The longer answer is, “The team is moving far too fast for you to miss the various hallway conversations which randomly point us in different directions.”

Software is art. It’s team art. When the team collectively decides to start painting blue over a round of stiff drinks, you, as a remote employee, are going to look pretty silly come Monday when you’re still painting red. It’s this communication latency that troubles me. I’d rather freely communicate rather than worry about whether or not I’m freely communicating or not.

My remote employee policy has been taking a beating for years. First, we, as a software development community, continue to spread out. It’s entropy at work and it’s being driven by insane home prices as well as ever improving means of high bandwidth communication with folks on the other side of the planet. Combine those facts with my impression that the population of qualified developers outside of the US is exploding and I’ve got a policy problem.

Ok.

I’ll adjust.

In fact, I have to as an employee recently made a run for the Northwest and there was no other option than to let him work remotely.

I’m ready to learn and that’s today’s question, “How do you, as a remote employee, stay in the loop?” The converse, if you prefer, is, “How do you, as a co-worker or manager of a remote employee, keep everyone on the same page?”

So far, I’m trying the following:

• Created an internal IRC channel where the team hangs for informal conversation
• Include the remote employee at staff meetings via iChat video conferencing. It sounds lame, but throwing the remote fellow on the 30” flat panel gives a solid visual cue that he’s there

What else works? Other tips? How are you making remote work?

Subtlety, Subterfuge, and Silence

Managers, wanna-be managers, and folks who want to understand managers simply need to read the 48 Laws of Power by Robert Green and Joost Elffers.

I’ve purposely not done any background research on this document because my first reaction to this list was profound and I wanted to stare at that reaction. There’s some pretty evil shit documented there as well as some basic truths about what managers are up do on a daily basis. I can’t tell if the guys who wrote this are serious when they write “Keep Others in Suspended Terror: Cultivate an Air of Unpredictability”, but after several readings, yeah, I think they’re serious.

My problem with this list and how it relates to managers is that some many of the “rules” involve psychological torture of those you’re trying to lead and that strikes me as a good way further the intense knee-jerk reaction regarding managers. “That guy is a power hungry jerk’.

Still…

Part of management is navigating your way through some tricky political jungles… Part of management is getting folks to comfortably bend in a uncomfortable direction. A good manager is a person who is playing to a strategy and isn’t merely stumbling around squashing fires all day.

Management is chess. When you’re presented with a problem, you sometimes need to sit back and take a look at the board, figure out the consequences of each of move, and, most importantly, pick a move. In my experience the move and how you pick it does not involve 48 laws, it’s only three words. Subtlety, Subterfuge, and Silence.

Subtlety

Worst performance review ever. I’ve just delivered a painful performance review to a fictional employee and he doesn’t get it. Two weeks I spent writing this thing, gathering peer feedback, and rewriting and he’s sitting there like everything’s dandy. I’m not about to fire this guy, but given his current trajectory, he’s two years from becoming irrelevant and I want to nip this in the bud, but it’s radio silence.

“Any questions?”

“Nope.”

“Are you clear about the areas I want to work with you on?”

“Yup.”

Now, the point of a performance review has nothing to do with the review, it’s the discussion. It’s about constructively conveying information about the performance of the co-worker and then chewing on it a bit. You want to see some form of processing of the information you just dumped even if it’s just a pile of follow-up questions.

I was getting nothing.

So I moved on. It was our 1:1 and I had a list. We started with the first item which, last week, read “Thoughts on moving forward on Project X.” This week it read, “Lack of progress on Project X, next steps, and goals.” The second item had read, “Hiring status” and this week it read, “Weekly goals for resume review, alternative sourcing strategies.” Yes, I’d rewritten my entire 1:1 with the performance review in mind.

The employee in question wasn’t comfortable with the strategic broad-strokes I’d painted in his review, but he certain got it when I carefully reconstructed his 1:1 to support the review. By the end of the 1:1, I’d piled his to-do list so high, we were actually back talking about the performance review because it was that advice that was going to help him get the work done.

To me, using subtlety as a manager is the ability to elegantly handle complex situations. This elegance, this ability to cleverly handle the complex, only happens when you have time to consider your response. That’s the other half of subtlety. It’s the ability to look at what’s happening around you and make a make a distinction between useless noise and emerging relevance.

Subterfuge

Say it with me, “sub-ter-fyooooooooj”. We should make shirts, it’s that fun to say, but what does it mean? Subterfuge means “intrigue, deviousness, deceit, deception, dishonesty, cheating, duplicity, guile, cunning, craftiness, chicanery, pretense, fraud, fraudulence”. Those definitions cover a lot of territory, so let’s refine it for the sake of this piece.

Relative to management, this does not mean “deceit, dishonest, cheating, fraud, or fraudulence”… it’s everything else. I’ll explain.

We were at a crossroads at the start-up. Too much to do, two vastly different directions in which the team wanted to head. There were the infrastructure folks who wanted to spend three months replacing the application server and then there were the interaction folks who wanted to improve the usability of the application. The VP listened to both sides and then he decided, “Infrastructure! Long term scalability!”

The interaction folks were pissed. Their response, “Who cares about long term scalability if no one wants to use the product?” Oh yeah, I was also the manager of the interaction folks and I agreed with them, but I had to throw my engineers on the infrastructure work because we didn’t have the capacity. I was talking with existing customers and they weren’t pulling their hair out because the application was sluggish, but rather because it was an interaction nightmare. They were spending most of their time trying to figure the damned thing out.

Grrrrrrrrr.

The lead interaction designer, myself, and an engineer sat in a conference room fuming in silence when it popped in my head. “Hey, people are visual creatures, how long to throw together a prototype that shows off what we were thinking?”

My engineer, “A week!” Good time to point out how enthusiasm reduces all engineering estimates by a third. My engineer continued, “But I’ll need Frank.”

Hmmmmm.

“Here’s what we’re going to do. I want you and Frank to work on this after 5pm, after we’re done with our infrastructure work, and I want you to keep this on the downlow. If, after a week, we like what we see, we’re going public.”

Herein lies the hard part of subterfuge. Depending on where you are standing, my plan could be viewed in any number of ways. The other engineering director would have called it, “Disobeying a direct order” whereas my boss, who got wind of the effort two days in, called it “a skunk works project” and told us to proceed. Phew.

Our skunk works took us three weeks, not one, but when we showed off our work, the VP of Engineering and VP of Marketing were impressed and wanted to see us finish the work. Rather than sacrificing the infrastructure effort, they gave me two reqs so I could hire a team to do the job right.

Subterfuge is a risk. The infrastructure director never quite trusted me after that even though I still went out of my way to keep him in the loop after we went public with our work.

The use of subterfuge for good means keeping the intent honest. If you’re going commando to do what you believe is right, it doesn’t means someone isn’t going to be pissed, but it should allow you to sleep at night.

Silence

Your most annoying employee sits across the table and he’s on a roll. This guy is total and complete personality clash with you and he’s in his second hour of rambling about something you don’t understand. My advice is simple:

Shut up.

I mean it.

Now, if you know what he’s trying to get at and you’ve continued to let him blither, ok, you can start talking and directing him elsewhere, but if he’s valiantly trying to get to the point, you must shut up and listen. Your silence is giving him a chance to get something out.

I’m not a fan of public speaking. I’m not comfortable with the all hands meeting where I’m laying out the next six months of work. My natural state is one of introspection where I’m soaking in the world and the skill has taken me far because so many folks out there just can’t shut up. While all this talking is going on, I sit quietly and nod… learning what all these yammering people are about and carefully file it away for future reference.

Managers lead and a lot of managers translate that into “managers lead by talking”. Combined with the tendency of employees to not say no to these managers, you can see why a lot of us have turned into professional windbags. We think we’re guiding you by filing the air with our thoughts. There’s a time and place for that, but in order to fill the air with something relevant, you’ve got to gather and process data.

In silence, you can assess.

My favorite use of silence is a huge cross-functional meeting with a group I’ve never worked with before where I have no role other than listener. It’s a table full of people I don’t know and I feel like I’m sitting at the worst poker table ever because everyone tells you what they got.

Remember this, in most business, everyone’s basic agenda is visible after they’ve talked for about ten minutes. I’m not talking about who they are as a person, I’m talking about figuring out what they have and what the need. In poker, you keep this information hidden as best you can because your money is on the line. In business, everyone throws their hand on the table, stands up, points at their hand, and says, “People, I’m one card away from the nut flush. Who’s going to give the queen of hearts?”

Asking for what you need is a good strategy in business, it’s called collaborating. Each time I hear “I need”, I learn another bit about those I work with and, in time, I can construct a better picture of how to interact with my co-workers.. Still, I’m also wondering about that guy in the corner who isn’t saying a thing. His eyes are darting around the room just like mine and I’m curious… what is he getting out of his silence?

Business isn’t War

The 48 Laws of Power are the real deal, but they are focused on war, not business. There’s a book if you want to know more, but read wisely. With each successful year on the job, I find myself adjusting to the ever increasing complexity with which my peers play the game of management. Fifteen years in, I can safely say there is one law which is true; if you’re only interested in building power, you’re going to lose.

Ode to a Chain Saw

Everyone at work chuckles when I, once again, tell them I was out with the chain saw this weekend. They’re laughing because they’re trying to picture their nerd boss act like a mountain man. Fact of the matter is, I am a nerd. I do call Verizon every month or so to see when they’ll be lowering my DSL price and increasing the speed. I like futzing with my Tivo and I can program in C++. I also love my chain saw. Deal with it.

I have fond memories of the smell of a chain saw. My Dad has been using them for forty years, so I grew up with the stench of burning gas and fresh cut wood. Still, The Dad was bright enough to keep me away from the chain saw until I was ready. I’m the guy who killed an orchard with a Volvo when I was eighteen… we called it “vehicular orchardcide”. So, probably not a good idea to let me near lethal weapons until I turned twenty. He waited until I was thirty.

The previous home owner left me a chain saw, so I’ve been busy. Fire wood, you see. Oh yeah, kindling, too. What’s that? Need those bushes trimmed? Be right there. Waitwaitwait, let me clean-up that Christmas tree for you. I HAVE JUST THE THING.

Since this piece is really going no where, I leave you with this — it’s a list of how your many skills as a manager are like a chain saw.

• Both require constant attention
• You need to be standing flat on both feet before you get started
• Getting in the way of either when they’re doing their job well is a bad idea
• When used correctly, it’s always surprising how well they work
• The art involved is sometimes subtle
• A poor split second decision can have instant and, sometimes, lasting consequences
• Sometimes just starting the damned thing is a bitch
• Both appear intimidating at first, but are actually quite easy
• When you stop respecting it, you get burned
• If your blade is dull then you are wasting your time (Thanks Matt)

Saying No

Somewhere in your third year of being a manager, the Management Pixies will appear in your office in a puff of sweet smelling black smoke. There will be three of them and one will be carrying a gorgeous black top hat.

“Are you LeRoy McManager?”

“I am.”

The Pixies laugh. “Congratulations, you have passed successful through three years of management and we’re here to reward you, but first, one question: Have you seen Spiderman?”

“The first one or the sequel?”

“The first one.”

“I have.”

The Pixies laugh again. “What do you think the primary theme is in Spiderman, LeRoy McManager?”

“Um, hmmmm… life’s a bitch?”

Strangely, the Pixies don’t laugh. “No, try again. It’s important.”

“Ok, well. Hmmmm… Peter’s Uncle said something they kept yammering about… OH I KNOW… With great power comes great responsibility.”

The Pixies cheer and the one carrying the top hat flutters over to you and drops it in your lap. It’s soft and strangely warm. The hat-bearing Pixie looks up at you and grins, “You wear this hat when you want people to know who you are.”

“And who am I?” You look down at the hat and notice massive white block letters on the front, they read:

I’M THE BOSS.

A slow grin stretches across your face and you realize the hat has the vague smell of your Mom’s fresh baked bread. That smell has always given you a strange sense of confidence and you know that whenever you wear that hat, you’ll been infused with that sense of confidence.

All three Pixies leap into the air giggling, “Good luck LeRoy McManager, use your hat well!” More laughing. Another puff of black smoke and they’re gone.

You lift the hat slowly in front of your face, staring at the white block letters, soaking in the sense of power the hat gives you, and you put it on.

You stride out of your office never once wondering why the Pixies were giggling so much because, well, you’re the boss. The first person sees you walk by in your cloud of confidence and, once you walk around the corner, you don’t hear them snicker because, again, you’re the boss.

They’re laughing because while they know you’re the boss, they can see the other side of the hat and it reads.

… FOR NOW.

Managers can lose it.

I mean it. There are managers out there who are absolutely punch drunk with power and if you’re working for one of these folks, I’m really sorry. You’re a resident of Crazy Town and that means you never know what random crap is going to happen next and that sucks.

Manager’s don’t start crazy. It’s an acquired trait and this article explores what I consider the single best tact you can take to avoid a trip to Crazy Town. Let’s tackle it first with a story from an employee’s perspective.

You’re merrily typing way at your keyboard, hard at work at the next great feature when your boss walks in and says, “Hey, can you work on a Gizzy Flibbet?”

“Uh, isn’t the Flubjam the key feature? I’ve barely even started it. It’s going to take awhile”

“Oh yes yes, we’re still doing Flubjam, but I need you to prototype the Gizzy Flibbet and I need it in two days for a meeting with the Execs.”

“Oooooooook, you’re the boss.”

“That’s right, I am the boss.”

Two days pass and you pour your soul into the prototype feature. Like all investigations, you discover each step of discovery takes three times as long as expected. The final prototype coveys the idea, but the process to create that result has left you drained and pretty sure finishing the remaining work is going to take a really long time.

When your boss walks into your office, you summarize, “Here it is. It looks good, it’ll take awhile and I’m now very behind on my Flubjam work. Can I please get back to it?”

Squinting her eyes, she runs her fingertips along the front rim of her top hat. She nods and stares, “Ok, THIS IS GREAT. Let’s do this AND Flubjam AND let’s hit the same schedule! Go us!” She turns and leaves the room leaving your office with the faint smell of bread.

I’ll recap. Your boss has just picked the one scenario that involves the most work and has the least chance of succeeding. You’re screwed and while you might think your boss has lost it, you are a co-conspirator in this disaster because you didn’t do one simple thing, you didn’t Say No.

Losing It

Manager don’t lose it simply because the Pixies showed up with the top hat, they lose it because those they work with forget to look at the back of of the hat. Remember:

• Front: I’M THE BOSS
• Back: … FOR NOW

Management is myth… just like the top hat. We, as employees, believe it’s there, so we treat these management types different. Yes, they sign the checks and they write the reviews, but, in a perfect world, those events are a function of your performance and not theirs, so it’s your job to not screw that up. I realize that’s a big fat stretch, but stick with me.

What is the real source of a manager’s perceived power? It’s the idea that they can make decisions. When the the team is stuck on a problem, they gather up in the manager’s office, present their case, and the manager nods and says, “Go that way!” More often than not, everyone is so happy to be past the logjam, they don’t even question whether it’s the right decision or not. “He’s got the top hat, so he must be right!”

No no no no. Also. No.

Managers lose it when they are no longer questioned in their decisions. When the team stops questioning authority, the manager slowly starts to believe that their decisions are always good and while it feels great to be right all the time, it’s statistically impossible. The most experienced managers in the world make horribly bad decisions all the time, the good ones have learned how to recover from their decisions with dignity, but, more importantly, help from the team.

Let’s take a look at Saying No from the manager’s perspective without any Pixies.

Back at the start-up, we were considering the move to a hosted model for our web application. I, in my third year of management, was in charge of presenting the pros and cons of such a move to the Executive Staff. We were in the middle of three huge deployments, so I decided to not put the necessary work into the presentation. I wrote it the night before and didn’t vet it with anyone. The end result asked more questions than it answered. It was a mess.

The Executive Staff went pretty easy on me. It was clear from their questions that they weren’t happy with my half-baked ideas and I left the room thinking I’d blown it.

The first person I saw after the meeting was Doug, one of my managers. Doug, “Rands, way to go! You hit it out of the park, man! When do we get started?” In my state of depression, Doug’s enthusiasm for my crappy presentation was intoxicating. Maybe I was being too hard on myself? Maybe it was a good presentation and I’m just being too sensitive? Yeah, that’s the ticket.

The second person I found was Randy, my other manager. His comment, “Ouch. That stung. What’s our recovery plan?”

Sure, I wanted to punch Randy, but he was spot on. I’d blown it and any other conclusion was a load of crap. The irony in all of this is that Doug believed he was doing the right thing by supporting me, but he was only eroding his credibility with me by not telling it straight. Think of it like this, if I’d swallowed the Doug Happy Pill, I would’ve done nothing to recover from my failed presentation and I would have looked like an idiot to the Execs.

What I did do was swallow the Bitter Randy Pill and completely redo the presentation along with the help of my managers. We presented a week later and actually did hit it out of the park. That’s with the truth gets you… progress.

No Versus The Truth

Randy didn’t Say No, he told me the truth, but I’m leaving this article entitled “Saying No” because I think it’s harder to contradict your boss than to tell the truth. Saying No forces an idea to defend itself with facts. Sure, no one really wants to hear their idea is crap. It’s hard to Say No and it’s even harder to Hear No, but who do you want to work with? People who are going to help you refine your direction or ones who will merrily follow your downward spin to Crazy Town?

As with every job, your success as a manager is the end result of innumerable decisions. While the front of your top hat reminds everyone that you’re the one making the decisions, the back of the hat reminds everyone else that, more importantly, you’re the one responsible for those decisions.

Management Cheat Sheet

There’s an article somewhere in my head which dissects the intense knee jerk reaction a lot folks have regarding managers. The question is, “Why do so many of us automatically assume that our managers are boobs?” The follow-on question is, “Even if we don’t think our managers are not boobs, why do we constantly ridicule them behind their backs?”

Clearly, the answer is rooted in our basic issue with authority. “Who does HE think HE is? More important than ME?” No, he’s just got a different job than you. Yeah, he’s probably got more to affect change now, but that he didn’t a few years back. He was you. So, what are YOU going to do about it?

The article needs to be written soon because my role continues to wander about the organizational chart and at each part of the chart, they serve a different kool-aid. This drink tastes great, but it slowly dulls my memory. It makes it harder to context switch to where I was versus where I am. Could be age, too.

To preserve these thoughts, I present you the Management Cheat Sheet. It leads off with a generic version of the Rands Communication Template and finishes with neatly organized lists of the various articles hiding on this site.

As you read the articles, you’ll notice I jump around a bit in terms of audience… sometimes I’m focused on the manager and sometimes on the employee. Here’s the point: There is no difference. Just because your boss can fire you doesn’t mean you can’t quit.

Rands Communication Template

People appreciate consistency… especially in business. They want to know what occurred today is likely to occur tomorrow.

“RANDS? HELLO? What about Messy Thinking? Signs of Art? Taking Time to Think? HOW DO I INNOVATE WITH CHAINS OF CONSISTENCY?!?!?”

Calm down.

Ever hung with a hardcore successful artist? Painter? Writer? I bet their workspace was a total disaster. I bet you wondered, “How is the world does this person produce their art in this mess?” They don’t produce, they create. There’s some studio or publisher out there who does the production and they need consistency because they’re responsible for the cash and the cash vanishes, the gig is up. Our artist can still create in this scenario, but can they eat?

The Rands Communication Template is document designed to allow you to consistently communicate with someone else. Maybe it’s your boss or maybe it’s your team. It doesn’t matter. What matters is that in your regular communication meetings, you are talking about the same stuff in the same way.

This template is a work in progress, but here’s the skinny:

• Using this template without modifying to your personal company/style is silly.
• This template is designed for someone managing multiple projects. Adjust to your load.
• Each of the mythical projects in the template are at a different mythical milestone. The content for each is adjusted accordingly.
• This document is intentionally one page — two columns. You should print it out and fold it in half when you use it. Two reasons: Sitting in front of a computer during a 1:1 is distracting and you should be focusing on communication with whoever is in the room. Also, keeping your notes short and to the point keeps you on message… less time consuming tangents. I can’t explain the folding thing, it just feels good.
• Almost every bucket on the template has an entry “Hot List Next Steps”. These are whatever festering problems you have in your program or project. These are items where a lack of a weekly forward progress is a career limiting move. It should be clear for each item what your plan is and when you’re going to execute on said plan.

My process with this document is simple. I update my template the morning of my meeting. To do this, I look at last week’s version for an interesting or hot issues I noted in the prior meeting. Ideally, I’ve already moved on these and have something to report.

During the meeting, I follow the order on the carefully folded sheet. People, Program, and Product. Success can be measured in two ways: healthy conversation during the meeting or awestruck silence. Your mileage may vary.

With feedback from y’all, I’ll be happy to continually update this document. I would absolutely love to hear from folks who have tried to use this document. I would absolutely love to see real world versions of this that folks have tried with the managers and employees.

Rands Communication Template v.02 (PDF)

Ok, useful articles:

Understanding the Team

These articles focus on figuring out who the hell your working with and for. I have a tendency to map personalities on a spectrum where they are either THIS or THAT. In reality, there are multiple spectrums and the following articles describe a bunch of them:

• Free Electron — the single best engineer you know
• Organics and Mechanics — fuzzy thinkers versus the machines
• Inwards, Outwards, and Holistics — managers are not evil
• Incrementalists & Completionists — better is the enemry of done
• Healthy Tension — r&d versus qa

Understanding the Company

Ever wondered why there are useless meetings? Confused by your new company’s lingo? Not clear why your boss is yelling at you? The following might help:

• Mandate Dissection — deliver and receive big news
• Agenda Detection — understanding the players and pawns in meetings
• Managementese — communication across the org chart
• Rands Management Glossary — evolving glossary of management mumbo jumbo

Improving the Team/Yourself

Constant improvement only comes from constant challenge. How you communicate and deal with that challenge will define you as an employee, a manager, or a soon-to-be-unemployeed loud mouth:

• Don’t Be a Prick — do unto others
• What To Do When Screwed — high velocity management
• How To Lose Your Job, Pt. 1 — understanding stagnation
• Avoiding the Fez — fixing stagnation

Creativity in Development

It’s relevant that the last section is the most fun. Figuring out how to build stunning products is job #1. I can help:

• Taking Time to Think — are you thinking or reacting?
• The Bear Story — art won’t die
• Messy Thinking — you need space to think
• Pitch — and a great pitch
• Signs of Art — because software is art

Signs of Art

There’s a never ending battle going on in your software development team right now. It’s the battle between the Organic Engineers and the Mechanical Engineers and it sounds like this:

Organics: “Software is art!”
Mechanics: “Software is logic! It’s fact! And it’s a lot of work.”
Organics: “You’re right! It’s work but it’s artful work.”
Mechanics: “When you call it art, you trivialize our work. I design lightweight database libraries and it took my team of four engineers 18 months to roll out last version and it’s compliant with RFC 2354 and blah blah words acronym words blah blah.”

It’s at this point the Organic glazes over and starts dreaming about how they’ll design a stunning application on top of this whizbang database.

As I’ve said before, we need both Organics and Mechanics (as well as Incrementalists and Completionists) to get our bits out the door, but what I really want to say is…

Software is art.

The follow-up to this statement is “What is art?” Brighter folks than I have spent their careers working on this question and I’d like to apologize in advance to each one of them. I’m just some schmoe sitting on the floor of an airport waiting for my flight, but I’m going to take a stab at definition.

Art is “the documentation of a thousand interesting decisions”.

Let’s take that apart word by word:

“The documentation…” In order to qualify as art, you’ve got to be able to share it with others. This means capturing it on some canvas whether it’s paper, a DVD, a web page, a city, or your skin. If you can’t share your art, it’s not art. It’s a conversation with yourself and I’m sure you’re fascinating, but why not share it with the rest of us?

“… a thousand…” A thousand is a swag. It describes that there needs to be some perception of effort for a work to be art. I’m specially YELLING AT YOU MODERN ART because YOU OFTEN FAIL THIS TEST. A matchbox poorly glued to a large piece of purple construction paper is not art. Sorry.

I’m not suggesting that an outside observer needs to look at art and say, “Gee, that looks hard to do. I couldn’t do that.” The observer needs to experience something in the piece whether whether it’s the size, weight, or complexity of the work and can’t be created with a single trivial decision.

“…interesting decisions…” Now, here’s the heart. Art is is when someone captures a set of decisions worth remembering. Blue or red? Serif or sans serif? Ruby or Python? San Francisco or New York? Up or down? As I said above, one decision does not art make (STILL GLARING AT YOU MODERN ART), it’s the collection of all the decisions… captured… that create a conveys a unique idea to the observer. It’s not just whether they can see/hear/feel this idea, it’s whether they find inspiration in their aggregate perception of these decisions. It’s a personal thing. Some decisions will inspire, some will bore and the sum of all the decisions will affect each person differently.

Software is art.

It’s a thousand decisions captured in code and displayed as user interface, services, and any number of other useful and artful conveniences. I would further argue that a great piece of software has equal ability to change the world as any great piece of art and if you disagree, I direct you to exhibit A, B, and C.

Believe it or not, that’s just introduction to this piece. What I really want to talk about is my secret Software as Art checklist. This is my personal list of discrete events I watch for in a team which engaged in the practice of building artful software.

This list will annoy every program management lovin’ mechanic out there. I swear I tried to shake as many of them off with the whole fuzzy (yet relevant) art introduction. If they’re still here, I need to say that I’m not suggesting that the following is a means of gauging a project, it’s a means of taking the temperature of a process which is creating art. I will further frustrate everyone reading by merely giving you a means of measuring without suggesting how to improve your team environment. That’s another column or two.

Measuring Team Art

Teams which are building art display the following traits:

1) High tension at inflection points. Traditionally, folks start yelling whenever you move from one development phase to the next. Sometimes there are formal meetings around these transitions, sometimes not, but what I’m looking for in the yelling is a team that is choosing to challenge the process.

If you’re moving from design to development, folks should be asking questions like, “Do we have the right features?”, “Has anyone bothered to write specifications?”, or “I don’t understand the vision for this product.”

If you’re moving from developing to deployment, the questions are different, but similar in tone, “Have we fixed enough bugs?”, “Do these features work?”, “How’s our Beta going?”, or “Does anyone else but me think this is crap?”

The key to this tension is not that folks are tense, it’s demonstrating that they are engaged. They know these development inflection points are critical public decision points and if they’re taking the time to care then they’ve got skin the game. Art is never created by those who are following the process.

2) Ideas appearing out of no where. Love this. You’re wandering the hallways on a Saturday afternoon and two engineers are idly talking about Feature X. It’s a casual conversation, so you plant yourself against a wall and listen in and WHAM HOLY SHIT she just totally redefined Feature X with an off-the-cuff comment. SOMEONE WRITE THAT DOWN.

As I mentioned in the Taking Time To Think piece, great ideas only come when you’re soaking in a problem. Hallway brilliance only comes when the team is breathing the product.

3) Efficient Decisions. Another good sign that folks are busily creating art is they are making their own decisions. This might be hard for a manager to swallow because you’re getting paid to lead, but, trust me, you want the folks staring at the code to know two things:

• They can make strategic, big decisions all by themselves, but…
• The more folks they involve in the decision, the more art they create.

When you combine “efficient decisions” with “ideas out of no where”, you’re really cooking. A lot of folks freak out when they see a brand new feature in the product two weeks before the feature complete milestone. Yeah, it’s called feature creep and it’s hard to ship a moving target, but it’s worse to ship bits that are uninspired.

4) Evening and weekends. The traditional senior level productivity measurement is, “Is the team working weekends?” Senior execs believe a team really needs to “burn it at both ends” to ship a product. Furthermore, they believe that providing food for said weekend week is an incentive. Here’s your wake up call folks:

No one ever worked a weekend for free tacos.

When it comes to weekend and late night work, the question is not “Are they?” the question is “Will they?” Success here is a simple measure. Does the team go the extra mile without being asked? You see this behavior in start-ups all the time because the team knows who the team is. “It’s me and these three other guys and if we don’t do it, no one else will.” In larger companies, this perception is diluted because there is so many frickin’ people. It becomes, “Well, someone is going to fix this, right? Right?”

Measuring Despair

At every entrance to the Silicon Valley there’s this huge road sign. It reads:

You’ll notice that the sign says nothing about art. That’s right. You can do better, faster, and more and make scads of money without a smidge of art. Is that company you want to create? To work for? Really? Bummer. You can stop reading now.

If you’re still here, you know that the combination of a desire to build art and the BetterFasterMore mantra will invariably lead a development team to believe it’s screwed. No matter how inspired, creative, or innovative the group can be, they will arrive at an psychological impasse where all will appear lost. This is where you, the manager of people, will realize a couple of things. First, even though you’re no longer contributing code, the decisions you make regarding moving the team past despair is your essential contribution to the art that is your software. Second, you are responsible for the flavor of despair the team is experiencing.

One flavor of despair tastes like that last sip of coffee that’s been sitting in that paper cup all day. Cold, useless, and full of coffee grinds. It’s got a hint of promise, but it’s mostly an empty reminder of what was…. it’s depressing. The other flavor of despair is metallic in taste… it’s the flavor that floods your mouth when you’re being chased by a bear. It’s scary, but the adrenaline is kicking in and that means SHIT WE’LL JUST RUN FASTER.

There is a flood of management terms which change the taste of despair. Empowerment! Collaboration! Thinking outside the box! These words pasted on big fat pieces of paper and slapped all over the building do exactly one thing: they clutter up the joint. Changing the taste of despair and building a team that wants to create art is a full time gig and I’ll spend a lot of time writing here about how to do it. Sorry to leave you hanging, but I’ll leave you with a simple observation.

If you’ve got a team full of bright artful people, they’re going to have endless opinions about what is art and what is not. They will argue, they will yell, and there will be times when you hate the person you respect most because you are incapable of admitting they are right. This roller-coaster of pain and pleasure always ends at the same spot. It stops when all of the team’s hard-work is judged by one person — the customer. A finicky, opinionated person who will make the most important decision — is it art?

Taking Time to Think

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

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

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

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

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

REACT versus THINK

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

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

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

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

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

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

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

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

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

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

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

GETTING STARTED

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

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

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

PLAYERS

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

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

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

CONTENT

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

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

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

IS IT WORKING?

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

Good work. Really.

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

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

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

WHEN TO STOP

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

FIGHT STAGNATION

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

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

Don't Be A Prick

With the completion of the Fez column, I have enough content to start stitching together a book based off my various management essays. Book publishing has never been a stated goal, but based on the response to many of the articles, there’s a good chance folks outside the webosphere might find my management musings of interest.

Problem. What’s the pitch? BE A GOOD MANAGER? ZzzzzzzzZ. There are hints of themes amongst the various management articles, but there is no single article which sets the stage for the rest… that hints at a basic truth that ties my reposing together.

There is now…

Flashback to the middle of the dotcom implosion. We, the merry crew of the failing start-up, are drinking… a lot. There are various bars around corporate… each have a distinct purpose. There’s the dive bar that’s great for post-layoff parties. The booze is cheap and if you’re looking to blow off some I’m_Really_Not_Worthless steam, you can pick a fight with the toothless sailor slung over the bar or the guy who just laid you off.

Down the street is the English pub. The beer is better, they have a selection of whiskey, and they have edible food. This is where we get philosophical about the current organizational seizure we’re experiencing in our three year slide towards irrelevancy.

We’re there now. We’re drinking heavily because the company has just been sold to a no-name public company who will quickly dismantle the company we’ve bled for. Everyone knew we’d be here at some point, but no one expected to be the last one standing. And no one expected the CEO to show up.

This isn’t the CEO that built the company. He’s been gone for over a year. This is the guy the Board of Directors brought in to sell the start-up. Sure, he tried to turn us around, but, remember, we’re in the middle of a financial nuclear winter here. Money is no longer free.

Those who got a glimpse of the CEO’s resume before he arrived knew the gig was up. His last four jobs ended in the company being finely sliced into into nothingness. It’s called “maximizing shareholder value”.

And here we are. Hammered on tequila… the last four from engineering. Two guys from tech support… and the CEO. Even though we’re dizzy with booze, we’re fundamentally uncomfortable with the presence of our CEO because we consider him to be an unfeeling prick.

And that’s it.

That’s the title of my management book.

“Don’t be a prick.”

Right so, the editors are probably going to have an issue with the word “prick” in the title. It falsely implies a masculinity to management which is a crock, so we’ll call it a working title until the actual editors show up.

The CEO in question is not a prick. Good guy. Straight talker. Good financial sense. Many failing companies did a lot worse that ours, but that isn’t the point. The reason we sat there drunk and uncomfortable was because we had absolutely no connection with this guy. He was the mechanical CEO.

My definition of a great manager is someone that you can make a connection with no matter where you sit in the organization chart. What exactly I mean by connection varies wildly by who you are and want you want and, yes, that means great managers have to work terribly hard to see the subtle differences in each of the people work for them.

See. See the people that work with you. They say repetition improves long term memory, so let’s say it once more. You must see the people that work with you.

If you don’t have an inkling of what I’m talking about yet, it might be a good time to set this (potential) book down and head over to programming section of the book store because it’s time to reconsider that pure engineering career tract. Being a manager is a great job (I mean it), but it’s your ability to construct a insightful opinion about a person in seconds that will help make you a phenomenal manager. Yes, in a technical management role…, you need both the left and right sides of the brain, but just because you write great code doesn’t mean you’re going to have a clue about how to lay off 70% of your staff.

Every single person you work with has a vastly different set of needs. Fulfilling these needs is one way to make them content and productive. It is your full time job to listen to these people and carefully mentally document how they are built. This is your most important job. I know the Sr. VP of Engineering is telling you that hitting the date for the Project is Job #1, but you are not going to write the code, test the product, or document the features. The team is… and your job is the team.

I know the Silicon Valley is full of wildly successful dictators. These are the leaders who are successful even though they are world class pricks. This book is going to push you as far from prickdom as possible and if that means I’m decreasing the chance you end up on the front page of the Wall Street journal labeled a “corporate bulldog with vision”, well, I’ve done my job.

You get to choose the type of manager you will be and if you want to work with your team, if you want to learn from them, if you want them to trust you, well, I’ve got some advice for you. Lots of it. Keep reading.

Again, the CEO at the start-up was not a prick. He just showed up at the wake for the company and assumed that we’d be comfortable with his presence because HE WAS THE CEO. We knew he was CEO. More importantly, we knew he’d spent exactly zero time using our products. We’d never seen him there on the weekend. Come to think of it, he was never there on Friday either because he commuted from another state. We had no shared experience with him other than three strange meaningless all hands meetings filled with slide projectors, spreadsheets and monotony.

The CEO believed that these spreadsheet-laden all hands meetings were all the connection he needed to build and, for the duration of that meeting, he was right. We felt well informed after his meeting, but our needs were different a week later when rumors of layoffs started up. They were drastically different a month later when that layoff went down and the CEO was nowhere to be seen.

Organizations of people are constantly shifting around. They are incredibly messy. In this mess, judgments of you and your work will be constructed in moments… in the ten second conversations you have in the hallway… in the way you choose to describe who you are.

Meanwhile, you need to constantly assess those you work with, determine what they need, figure out what motivates them. You need to remember that what worked one day as a motivational technique will backfire in two months because human beings are confusing, erratic, and emotional. In order to manage human beings in the moment, you’ve got to be one.

And that’s why a better title for my book is:

“Managing Humans”.

Big Bad Conflict

Some time during your tenure as a manager the sky is going to fall. I’m not talking about a schedule slip or a spirited meeting or being screwed. I’m talking a total disaster… yelling… fighting. Best case, HR is involved. Worst case, so are lawyers. This is conflict of a magnitude you’ll only see a few times in your life… and you’re in the middle of it. Sorry about that.

Bad news first. I can’t help prepare you for this particular disaster because it’s of a unfamiliar make and model. Every team, product, and company is different which means your particular disaster requires insider knowledge which I don’t possess. My brief advice is always… if the shit is hitting the fan… call HR. They can help. They can fortify.

What I want to talk about is how your worst break-up ever prepares you nicely for this disaster.

Rough segue, I know, but bear with me.

First, we need to set the wayback machine for that time your were dumped by the love of your life. You know, the one where after the deer was done, you were barely recognizable to your self. It’s the one you swore you were going to climb into your car and drive to the other side of the planet because life was over as you knew it. Sure, you didn’t actually do it, BUT YOU SURE MEANT IT.

I’d like to propose a moment of collective weblog silence for all break-ups like this because, wow, they suck.

Ok.

We get over these break-ups not because time passes it’s because whoever dumped us usually comes back… several times. I mean it, as long as there is no restraining order involved, the person who dumped you calls you back and you both do something which you both think is stupid, but is actually quite healthy. You hook-up again in some fashion. Then, one of your quickly realizes why you broke-up in the first place and the break-up occurs again… and again.

This happens so reliably in my relationships that, later in my life, break-ups became slightly less painful because I knew that while she was dumping me that she’d have to call in the next two months because, at some point, she’d just remember more good stuff than bad stuff and wonder why we broke up.

Call ‘em relationship bounces because I think the whole break-up process looks like a bouncing ball. The moment you break-up you drop a big red ball on a flat surface… metaphorically. Time passes, the ball hits the ground with a decent amount of force and proceeds to reach another peak which is never as high as the original. This peak represents a relationship bounce where you plus your significant other briefly relieve your relationship. Repeat as many times as necessary which each peak representing an ever small bounce of the relationship which eventually fades.

Now, we’ve all sat in a bar with our friends telling us how stupid is to hook-up with your ex, but I’m here to tell you it’s a brilliant idea. Each bounce is a chance to heal because the last person you should be talking to about being dumped is your friends… they’re telling you what you want to hear. You should be talking to the dumper because they have the most information… and they convienently always come back.

Relationship bounces help you heal.

You are now officially wondering how in the world I am going to tie this back into the corporation. Here it is: Major conflict follows the same pattern as a bad break-up… it’s never over after the first event. It echos… it rebounds… and, as a manager, you need to be aware of this pattern for a couple of reasons.

First, you need to understand that whatever your conflict is… it’s going to coming back. You’re going to be seriously relieved when the first storm passes, but you need to immediately prepare for and possibly induce the next bounce because it’s coming… someone is going to yell again… someone is stewing in their office right now and your job is be ready for the next conflict.

Second, each bounce should be progressively smaller because you know it’s coming and are doing something to prepare for it. The worst case scenario is when the original conflict occurs and the second bounce is as bad or worse… we call that escalation and escalation is a sure sign someone is asleep at the wheel.

Third, and lastly, just like a bad break-up, these rebounds are essential. Sure, there will be more yelling, but when someone is yelling, they are working on something… they are, hopefully, making mental progress on whatever it is they are trying to communicate. When I found myself staring at the middle of a big bad conflict, my first thought is, “How am I going to make the next bounce happen faster?” You read that right. I want bounce number two because that brings me even close to bounce number three. See where I’m headed? Subsequent smaller conflict bounces means we’re making progress and are ever closer to resolution.

The number one thing to remember about big bad conflict is that, just like horrible break-ups, people are about as emotional as you’ll ever see them. Conflict is not the time to make decisions, make judgments, or really do anything except try as hard as possible to calmly weather the storm. You’re human so you’re going to be tempted to jump into the emotional fray, but that’s not your job.

Your job is mediation, you are neutral, and each passing moment of conflict is making you a stronger manager.

Organics and Mechanics

Stop. Grab a pencil and write down the first and last names of your past three managers. Stare at those names for a bit and re-live those months or years of reporting to this person. I want your off-the-cuff opinion about each one.

My guess is your opinion falls into one the three buckets:

I love this guy. Best manager ever. I still talk to him on a monthly basis because this guy taught me everything I know about what I do. He is my mentor.

Mostly harmless. This guy doesn’t really challenge me, but then again, he’s not really slowing me down. I’m not learning much, but I don’t have to put up with much bullshit. Also, I’m not sure what he actually does, but he leaves me alone… so… whatever.

Worst. Manager. Ever. This guy makes my life a living hell. I dread our weekly 1:1. I prepare for an hour and we still end up talking about random useless crap. It’s like we’re speaking a different language. I don’t know what he wants and, even if I did, I wouldn’t want to give it to him because I’m so annoyed. I mostly want to give him a poke in the nose.

I want to talk about Worst Manager Ever because, chances are, you’re right… you are speaking a different language and he’s just as frustrated as you.

As an individual contributor or a manager, you interact with two populations — those you work with and those you work for. The conversations with these two populations are distinct. With co-workers, you speak the Truth. You speak it because each of you are slogging out in your respective trenches, so what good is there to say anything but the Truth?

With managers, you speak the Way. The Way are the things we shall do to achieve organizational enlightenment. “Verily, I shall scribe a specification and it will be a good thing” or “Yea, it came to pass, I say unto you, I am working weekends.” The Way is however you’re communicating up to your manager. It’s different content and it’s different tone and if you believe you have the Worst Manager Ever then you’re not doing it right.

In order to understand how to speak to your manager, you’ve gotta figure out how they acquire information and, chances are, they either gather it Organically or Mechanically.

Your first job is to figure out whether you’re working with an Organic or a Mechanic. To do that, think of any problem as a very complex itch. Now, this is no normal itch, it’s a complex itch and scratching said itch is going to take some work. Here’s the inner dialog for a Mechanic and then an Organic regarding how their going begin their scratching

Mechanic: “An itch. Well. This itch seems familiar. In fact, I scratched this type of itch in January 2001. Let me first dig up my notes regarding that itching. Excellent. We’re going to need an matrix. The vertical column will be action items I can think of that will assess different scratching scenarios and the vertical axis will measure our progress against these different scenarios. Ok, we’re going to need a meeting to form a committee… “

Organic: “Wow, an itch. Hmmmm… well, this sucks. Hey Frank, we’ve got a itch… whaddya think? Yeah, that’s what I was thinking. You know, this itch seems familiar… I think I’m going to deeply consider this itch while I drive home, but, first, where’s Mary? She knows all about itches and I bet she’ll have some ideas… I wonder what happens when I type itch in Google… HEY… there’s an idea…”

Mechanics move forward methodically. They carefully gather information in a structured manner and store that information in a manner that makes easiest to find again. They quietly observe, they stay on message, they are comfortably predictable, and they annoy the hell out of Organics.

Organics are all over the place. They tend to be loud and they can tell a joke. They ask seemingly meaningless questions. They lean forward when they talk to you. When confronted with a horrible situation, you’re going to think they’re insane because they appear to be still smiling.

A large part of the managerial conflict can be summed up in the following scenario:

An Organic and a Mechanic are staring at each other across the desk and are thinking the following:

Mechanic: “This guy is walking chaos”.

Organic: “This guy is totally uptight.”

They are both right because they both violate each others sense of propriety. Knowing this solves half the problem. The other half is figuring out how the hell to communicate and that’s the hard part.

Prior gig, four years ago. I was hired in by the CEO as a Director while they continued to search for a VP of Engineering. As an aside, let me stress how bad of a career move it is to NOT know who you are going to be working for when you arrive. The thirty minute interview you have with your future manager is a critical piece of information when you decide whether or not to make a move. Here’s why.

The VP of Engineer showed up a few months later and he seemed like a bright guy. Good technical background… a bit quiet for my taste, but I’m loud so we’ll balance out, right? Our first 1:1 showed up, so I grabbed my big black notebook and plopped down in his office and WHAM HOLY MICROMANAGEMENT.

“What’s going on with this? How is Person X? What about Person Y? Have we done XYZ task? No, why? Why again? No really, why?” Question question question data data my lord does this guy think I’m sitting around surfing the web? Ok, deep breath Rands, it’s his first week and he’s gathering information so I’m going to cut him slack. He’ll chill out once he realizes I’ve got things under control.

Nope.

One month later and the barrage of questions is non-stop. This guy peppers me with random questions and I consistently leave his office feeling like I’ve been doing nothing WITH MY 72 HOUR WORK WEEK. It’s a cop-out to label this guy a micro-manager. Great, he’s a micro-manager. So what? I’m still going to walk out of his office on a weekly basis thinking I’m useless. He’s clearly Mechanical, but so what?

Remember, Mechanical managers gather information in structured way. They do this because they aren’t great at relating at people, so they let the left brain take over as a means of content acquisition. This means that if you have a Mechanic for a manager, you need to push the information in a structured, well known, and consistent manner.

For my prior manager, I wrote a status template. It started with products and listed current relevant bits for each of the products on my team. Following that, I listed personnel issues team by team. Contractor status, requisition status, vacations.

Each week, I’d fill this template out 24 hours before my 1:1. This was my first pass which loaded my brain with this week’s content. I’d remember things we’d talked about the week before and make sure that I’d have the most recent data on those hot issues. An hour before the the 1:1, I’d review again and fine tune. When the 1:1 arrived, I pulled out my print-out and started. I stayed on message and I never deviated from the template. Every week. The same structure chocked full of dates, data, milestones… anything concrete and real.

Consistency. Structure. He loved it. I literally jumped up and down after the 1:1 where he didn’t ask a single question because I predicted every single possible question he might ask.

My VP was a Mechanic and he wanted to feel the structure that encompassed dealing with every problem. Guess what, I’m a Organic. My 1:1s start with a “Hey, how the hell are you?” and then they wander. You’re going to walk out of my office thinking we just shot the breeze for a bit, but as we chit-chatted, I was carefully gathering content. What was your reaction to question X? What questions did you ask me? Yes, I appear to be collecting trivial crap with my random questions, but I tend to gather more information than Mechanics because who the hell knows what I’m going to ask.

That’s one situation. There are more and I guarantee yours is unique. My advice:

If you work for an Organic…

You’ve got to trust that they’ve got a plan even though it may not be immediately apparent. Don’t confuse an extremely open mind with cluelessness. Organics often have a more complete picture about what is going down because they are better networked.

If you’re a Mechanic, you’re going to feel a bit lost with your Organic manager because you’re OK with lightweight forms of micromanagement. It gives you structure. Most Organic managers I’ve worked with can put on a Mechanic hat and provide that structure, but you’ve gotta ask because it’s not their natural state.

It’s true. Organics often miss detail as they hurry from place to place.

If you work for a Mechanic…

Like I said above, a Mechanic will not believe you’re dealing with something until they feel the structure that encompasses a problem your solving. You must overload your Mechanic with data in order to satiate their structured brain. If your Mechanic keeps asking you the EXACT SAME QUESTION and none of your responses appear to be the answer, it’s time to counter with, “I really don’t know what you are asking.”

If you’re an Organic, you will wrongly assume that Mechanics don’t trust you.. and you’re right… they don’t. You will build trust by acting like a Mechanic with them. It takes practice, but since you’re already working for one, you’ve got a great role model. I’m not suggesting you need to transform yourself into a Mechanic (which is impossible), you just need to speak Mechanic long enough to sooth your Mechanical manager. Once he’s figured out you’ve got chops, you can start going Organic on him. He’ll deal.

Look out for…

Like Incrementalists and Completionists, the most dangerous Organic/Mechanic type is the switch hitter. My personal favorites are Mechanical Organics. These folks have all the slick tricks of Organic information gathering, but they’ve got the astounding organization skills of the Mechanic. They know everything and never forget a bit. I mean it.

Organic Mechanics are frightening. They have extreme depth of knowledge, but there is no obvious organic thread which ties it all together. Here’s the scary part. There is a thread. There is a purpose. They just aren’t letting you see it. Organic Mechanics will keep you on your heels and just when you think you’ve figured them out, they’ll change everything. I hate that.

The answer is in the middle

Organics doing battle with Mechanics or vice verse… is a waste of time. Organizational warfare does one thing… focus on the people rather than the business and that means you’re losing cash money. Whether it’s my manager or my co-worker, when I find myself in a Organic/Mechanic conflict, I think this:

“A purely Mechanical organization lacks inspiration. A purely Organic organization is total chaos.”

Organics fill Mechanical blind spots with their intuition and their passion while Mechanics create a healthy, solid home where nutty Organics can run into things at speed. It’s a team thing.

Avoiding the Fez

Ed: This article assumes you’ve read Part #1.

The first article finished with the big Rands revelation that it’s the manager’s job to figure out how to give Fez a swift kick in the butt. Yes, Fez needs to have the brains to listen and react to constructive advice, but that’s his deal. If I’ve done everything I possibly can to illuminate a path of growth to an employee and they’ve chosen to hang out in the dark, well, ciao Fez… unemployment is a terrific motivator.

Let’s start with the bad news. There’s no silver bullet to solve the Fez issue. Solving Fez is going to involve strategy, effort, inspiration, luck, and, lastly, a bit of time. You won’t solve it in a moment and you won’t solve it in a meeting.

There is a convenient yearly inflection point where everyone panics about their careers. Annual reviews. I’m going to construct this article around annual reviews, but I don’t want you to think that performing an annual review will solve the Fez. If you worry about career development once a year, you’re screwed. As you’ll see below, avoiding the Fez is a full time job, but since you get actual allocated time to stress about employee development why not stress in a constructive manner?

A BRIEF SIDEBAR ABOUT ANNUAL REVIEWS

People do care about cash. When that annual review begins, your employee is hanging on every word… carefully listening to your tone wondering, good review or bad review? If it’s sounding good.. that must mean cash; and cash rocks. If it’s sounding bad, they stop listening and start pre-bittering themselves for hating you for the next month since you clearly have NO IDEA where they ADDED THEIR VALUE this year.

Compensation adjustments are the result everyone cares about, but does anyone actually know how they’re calculated? What happened over the previous 365 days to result in a BIG CASH WINDFALL or an INSIGNIFICANT PITTANCE?

If you don’t draw a concrete line between a coherent understanding of an employee’s performance and their reward/punishment, you are only adding more fuel to the argument that “Managers sit around doing nothing all day”.

Let’s begin…

FIRST, GATHER YOUR THOUGHTS, BUT DON’T THINK (YET)

Here’s the deal. If I asked you right this second to tell me about your particular local Fez, you’ve already got a strong opinion, but it’s an opinion of the moment. It’s the latest three interactions you’ve had with your Fez and while those are relevant, they hardly represent a complete picture of the past year.

When you’re assessing an employee, you need to assess against their job, not the work they’ve done over the past two months. This is hard because this is the Silicon Valley and no one knows what happened two months ago… GOOGLE IPO THEN IPOD PHOTO THEN CHRISTMAS, RIGHT? DID I MISS ANYTHING IMPORTANT? IS TIGER OUT YET?

You did. Every month, your team produced something and it’s your job to document that production. I do this by spending an hour a month jotting down reflections of the team for the past 30 days. What stands out in my mind… What’d we do? Who rocked? Don’t get hung up on documenting every single event or talking about every single person… just type. Even if you miss massive contributions by a team member, the act of capturing your thoughts at the time they were happening creates a handy mental bookmark. This bookmark captures not only what you wrote, but everything else hiding around it so that when you go back and read the last summer’s terribly small entry:

“This month blew. No time to write.”

You’ll not only remember that y’all were on a death march, but you’ll also remember that Eddie the QA guy was there with you that weekend and, oh hey, he’s been here every single weekend and, wow, why aren’t we promoting him?

Regular snapshots of your team’s work will construct an impression of your team that you are incapable of constructing in the moment because, in the moment, you’re cranky about not getting coffee this morning, stressed about your product review next week, and DON’T GET ME STARTED ABOUT THE 300 MAILS I HAVE YET TO READ. How can you create an objective opinion of someone’s performance with all this crap in your head? You gotta step back, take a deep breath, and reflect.

As you sit there staring at the ceiling chewing on a year of thoughts, an overall impression is going to form… you can’t avoid it, but I’m asking you to ignore it for now. I’m going to distract you by proposing a model that you could use to look at your employees and begin to understand what exactly are their career needs. The model is Skill versus Will.

SKILL VERSUS WILL PLUS EPIPHANIES

It’s a simple graph. One axis is skill — how much skill does the employee have to do their job? Are the qualified? Over qualified? How long have their been doing it? When is the last time you know they learned something new? How quickly do they handle tasks compared to their peers?

The other axis is will — this is where we measure the employee’s desire. Do they like their job? Really? Have they told you that? Are they viewed as energetic by their team? When is the last time they generated a great idea that blew your mind? Are they talking in meetings or listening? Are they EVER talking? Are they ALWAYS talking?

This graph is not a precision instrument. It’s a tool to better define the impression you’re constructing of your employee. Once you’ve placed someone on the Skill/Will graph, you can begin to consider what your full time job is… constantly and consistently pushing your employees to the upper right quadrant… high skill (I’M GOOD AT WHAT I DO) and high will (I LIKE WHAT I DO). This mental map is your first step in constructing a Fez avoidance insurance policy.

“Rands, um, what exactly am I pushing constantly and consistently?”

Great question.

Worst case scenario. You’ve ignored everything I’ve said so far. You’re spending fifteen rereading your Fez’s review from last year… spending another fifteen throwing together this year’s review by cutting and pasting the one and only review you wrote for all your employees… making it unique by inserting their full name and project name. Dear Lord. You’ve really blown it.

Yet, you haven’t fully blown it. A complete fuck up is when you take this pathetic excuse for a review and present it. You say, “Employee 629, here is your review. You did this well, you did this poorly. Here’s your 4% increase and here’s your indecipherable objectives for next year. BACK TO WORK.”

You deserve every single Fez that you get. Please stop reading and move to a Red State. Thank you very much.

If you’ve taken some time to reflect on the full year… if you’ve mapped your employee against Skill and Will, you’ve probably had some epiphany regarding the Fez. You’ve realized, “Wow, they’re bored” or “She really has no clue how to architect software”. Great, an epiphany… it’s a start, but it’s not a finish. You are not the one who needs to have the epiphany — it’s your employee who needs it.

I’ll explain via the real fictional Fez. Go back and think about where you’d put him on the Skill/Will graph.. Your gut might say, well, he’s worked a lot of years, so he’s high skill and he’s just bored, so he’s low will

Nice try, but you don’t have the 12 months of fictional notes that I have. See, Fez’s skill used to be high, but it’s fading… it’s middle of the road skill now and the slow reduction is also affecting his confidence… his will. His diminishing skill is diminishing his will which, in turn, further diminishes his skill because he has zero confidence to go gather new skills. Yikes. A Skill/Will negative feedback loop. Didn’t see that coming, did you?

Here’s the upside. Just as Skill/Will fade together, they also rise together. If you focus on one, you often fix the other. It’s a brilliant management two-for-one.

Back to Fez. Let’s say your epiphany is to get Fez some technical training… send him to a C++ class and WHAM he’s going to be happy. HURRY, write that down as an objective because WOW you’ve really nailed that Fez problem.

Easy Eager Manager. Slow down.

ANOTHER BRIEF SIDEBAR — ASSERTIVENESS

I’ve got a a task for you and I’m going to ask you in two different ways. You tell me which request you’re going to actually do:

Request #1: You — go fix that bug.

Request #2: Hey, can you look into bug #1837?

The difference between these two requests is a management style which shows up in every personality test. You, Mr. Manager, are either ASK assertive meaning that you ASK in order to get stuff done or TELL assertive which means you TELL to make progress.

There are a great many charismatic leaders who’ve made billions by only telling folks what to do… I am not one of them. It’s not that I’m conflict adverse or that there are not times that I’m an incessant dictator, it’s merely I hate being told what to do, so I treat others like I’d prefer to be treated.

Telling your Fez what the problem is without belief on their part that a problem exists is tantamount to a personal attack. “You, Fez, are doing a poor job and I’ve decided that objectives x, y, and z are the only way that we’re going to save your job.”

I exaggerate for example, but I’ve had ten plus years of reviews and I’ve had some phenomenal managers turn a review into a speech about me… without involving me… and, well, I happen to be expert about me, so can I please be involved in the discussion?

An annual review is a discussion, not a speech. The goal of the discussion is to, first, agree that the review is in the ballpark. Remember, you’ve been thinking about the review for weeks because you’ve got a deadline… Fez is seeing it for the first time and he needs time to mentally digest. It’s very hard to be mentally nimble when you’re manager is staring you down asking, “Any questions?” It’s doubly hard when they’ve just told you you screwed up for the past year.

Rule of thumb. If you’re delivering big bad news, schedule TWO meetings. At the first meeting, you’re presenting the review… not the objectives. They’re going to want to know about compensation and you’re going to want to say it, but don’t. The moment you say “No increase”, the review is over, the employee is pissed and you’re going to be on the defensive. The meeting has become a mental fight and fights only prove who can punch harder.

It’s the second meeting where everyone involved has had time to digest the review. You can have a discussion about objectives because Fez drove home the prior night wondering, “My manager is telling me that I’m getting stale and I vehemently disagree with that… buuuuuuuut maybe there’s some truth in what he’s saying… Hmmmmmmm.”

With just a smidgen of agreement that the review is fair combined with you and your Fez agreeing about his place on Skill/Will, you can start talking objectives. What can do we to increase skill or will? New job? New tasks? Training? Maybe move him off that team of pessimists so they can spread their wings with some optimists?

Maybe get them out that the job of nay sayers so they can spread their wings with some optimists?

I don’t know what is up with your particular Fez, so I can’t advise specific objectives, but here are some high level thoughts about the extremes on the Skill/Will graph:

• High skill, low will. Boredom is imminent — needs a change of scenery/responsibility. Stat.
• High will, low skill. Needs training, needs mentorship. Needs management. The good news is they really really want it. Savor this because as soon as the skill kicks in, they’re going to start wanting your job.
• Low will, low skill. Boy, did you screw up. It takes a fairly concerted effort to ignore the needs of your employee so long that a) they no longer have the skills necessary to do their job and b) they don’t want to do it. Roll those sleeves up, pal. You’ve got work to do.
• High skill, high will. Great job, ummmmmm, guess what? No one stays here long.

BIG FINISH

Fez is career drift.

You’ve got some Fez in you right now. You may be the rockstar of your company right now, but you have no clue that three guys in a garage in San Jose are spending every waking hour working to make you irrelevant… they call it the New Whizbang and you’re going to hate the New Whizbang when it shows up because you know it replaces your corporate relevancy.

Your manager is not going to hate the New Whizbang because she doesn’t feel personally threatened by it. She is going to see you Fezzing out about it and, hopefully, she can figure out to trickle objectivity into your indignation.

I have a simple way of managing against Fez. I tell everyone I hire the same thing, “I hired you because you’ve got enough skill and enough will to have my job one day… whether you want it or not.” This statement tells those I work with that I expect them to succeed and reminds me to keep moving because there is nothing like having bright people nipping at your heels to keep you running.

Mandate Dissection

In your quiver of management skills, you’ve got a couple of powerful arrows. There’s the annual review where you take the time to really explain, in detail, what a given employee needs to do to grow. That’s huge. That can be life changing. That’s a big arrow. How about the layoff? That’s when you get asked who stays and who goes. You’re going to lose some sleep when you’ve got to pull the bow back on that one.

Then there’s the mandate. The mandate is when you gather the team together and calmly say, “This is the way it is.” No Q&A. No collaboration. It’s your dictate handed down from on high.

Most folks have learned to despise the mandate.

Rewind a few years back. I’m at my prior gig and we’ve just hired a new VP who, well, I really liked. This guy was sharp, experienced, had a litany of name brand companies on his resume, and he could tell a joke. Sold. Hired.

He was pretty quiet the first few weeks… checking out the landscape… sitting in on various meetings and listening. Engineering was in the process of discussing some drastic new directions for our products and the incrementalists (ship it soon!) were doing battle with the completionists (ship it when it’s done!). Tensions were high. Finger pointing, yelling… all the things you aren’t supposed to do in business.. but yet THEY FEEL SO GOOD when you KNOW YOU’RE RIGHT.

The VP’s second month arrived and we were still yelling. In my Wednesday 1:1 with the VP, he simply told me, “We are going to do it like this. End of discussion.”

Right so, of course I started spewing, “See, we still had to resolve issue #27 and, boy, were the completionists going to be pissed.. and had you thought about risk #12A? Blah blah blah…” He let me go for awhile and then he repeated himself, “We are going to do it like this. End of discussion.”

I might have nodded, I don’t remember.

As predicted, the team freaked. One completionist assured us he was going to quit. He slammed his door. The incrementalists weren’t happy either because they’d didn’t like being told what to do… they like to run the show. We had a good solid week of organizational disarray and… then we got back to work.

The new VP employed the mandate. He said, “I’m the guy who’s telling you the way it is”.

Now remember, I liked this guy, but, in the back of my mind when someone gives me an order, I don’t hear the order, I hear “Shut up, get moving, I don’t care what you think”. Your job as a manager is avoid giving this impression at all costs because it eventually erodes your credibility. I’ll tell you how.

There are three distinct phases to the mandate: Decide, Deliver, and Deliver (Again). Since you are the ultimate decision maker regarding this particular matter, we’re going to call this a Home Grown Mandate. These are opposite of external mandates which we’ll talk about later. Let’s begin.

Decide

Your first step is to decide when to employ the mandate and to also understand what the consequences are of laying down the law. There are thousands of little tiny decision you and your team make during the course of a day. A majority of these decisions come and go and no one is the wiser. Every so often, a big decision comes along. Doesn’t matter what the content is, what matters is that some portion of your team is on one side of the decision and other group is on the other side… and they’re arguing.

Collaboration, cross-pollination, debating, arguing… whatever you want to call the process… well, it doesn’t always work. Sometimes the team is so polarized that they start confusing the emotion with the decision. Rather than arguing the facts, they begin to argue from their heart and that is when you need to consider the mandate. Rule of thumb: When the debate is no longer productive, it’s time to make a decision.

My management style is to allow the team to argue as long as possible. I’ve got a collaborative management style because I know that the more brains and more time the team spends staring at an idea, the stronger the idea becomes. This means that decision-making in groups that I manage tends to be slower because I’m busy cross-pollinating, but I’m certain it means the our output is higher quality because we’ve taken the time consider what the hell we’re doing.

Remember that every person on the team that has a strong opinion regarding the decision, there are probably four other coworkers who just want someone to make a decision so that they can get back to work. We’ve each been part of the silent majority before… it’s the time when you choose to not engage in the heated debate. Maybe because you’re doing actual work or perhaps you just don’t care. You appreciate your silent status as you see the debate rage in the hallway… realizing how much pain, sweat, and tears you saved by staying out of it. When the team is still yapping away two weeks later, you start to wonder when someone is going to step up.

Mandates are the friend of the silent majority. Even if you really annoy the concerned parties, the silent majority will appreciate the peace and quiet once you’ve delivered your verdict.

Deliver

The purpose of this article is not to explain how to make whatever hard decision you need to make regarding the heated topic in your organization. I don’t know what the topic is, so you’re on your own. I will say that if you don’t spend time considering both sides of the issue before you Deliver that your team will know it and your credibility will be suspect. Those on the losing side will wonder why they weren’t consulted and then they’ll start wandering the halls murmuring that you’re either lazy or a tyrant. Ouch.

The goal of the Deliver phase is straight forward. You need to explain to the team that a decision has been made. Sounds easy, right? Well, this is where junior managers blow it. They do a good job of explaining the decision, but they fail convey that this is the decision and further debate is not necessary. A good sign of poor mandate delivery is when the delivery degrades into, yet another, debate of the issues. Delivering a mandate takes moxie… the team has got to leave the room knowing the decision has been made. They don’t have to like it, they may hate it, but they can not leave the room thinking there’s wiggle room in what you decided.

Again, an added benefit of this my collaborative management style is that mandates are less controversial because I’ve already vetted the various flavors of the decision with all the folks who have an opinion. When the mandate (finally) lands, it feels less like laying down the law and more like I’m relaying the results of our investigation. I still piss off those who disagree with the decision, but at least they got their say, right?

Deliver (Again)

Congratulations. You’ve delivered your first mandate and now you’re staring at a room full of heads nodding in the affirmative. Even the folks who have been screwed by your decision are nodding. Well done! There’s more work to do.

All that head nodding is a big ego boost, but the fact of the matter is that each person walking out of meeting has one of three distinct opinions:

1. YAY! — You are a Great Motivator. The winners will have this opinion of you, still you need to Deliver (Again).
2. BOO! — You are a Tyrant. Commonly held by those who’ve been screwed. You must Deliver (Again).
3. YAWN! — What took you so damned long? Silent majority here. Don’t sweat them… this time.

Delivering (Again) might be better called Damage Control, but that makes it sound like you screwed up by pushing the team forward… and you didn’t… maybe. Delivering (Again) is taking the time to individually express your reasoning to the concerned parties — both the yays and the boos. This not only gives you a chance to re-enforce what you mandated, but also gives coworkers the chance to respond in a non-team setting. Expect more venting. In fact, insist on it. If you’re sitting with someone who on the losing side of the decision and they’re still nodding their head, THEY DON’T BELIEVE THE BATTLE IS OVER. If you fail you get this person to open up, you will be mandating (again) in a few short weeks.

Delivering (Again) is not going to quench discontent in your team, but it going to give everyone involve a chance to speak up and that should push your management karma towards Motivator and away from Tyrant.

External Mandates

I’ve been talking about the ins and outs of Home Grown Mandates so far. These are situations where you are the decision maker which gives you access to a wealth of information as well as all of the players. In any decent sized organizations, you are equally likely to be on the receiving end of External Mandates. This is a mandate that occurs way outside of your sphere of influence.

Yes, the tables are turned. Mandates might just randomly show up and there isn’t a thing you can do it about it.

Guess what? The same rules from above apply with one exception. Just like your team, you are going to have one of the three opinions (yay, boo, or yawn) regarding the mandate. Regardless of what your opinion is, you must ask about mandate justification. What was the reasoning behind this mandate? You might have a Yawn-opinion about this, but what about the rest of your team? They might hate the mandate and boy are you going to look lame when you relay the mandate without a clue as why the mandate showed up.

Here’s the rub, mandate justification often does not travel well through a large organization. Either someone in your management food chain had a yawn-reaction to the mandate and didn’t bother to gather a justification or the grapevine has tainted the justification to the point that it no longer makes any sense. Either way, you’re going to be delivering news to your team sans reasoning. This blows. I’m certain that companies which exhibit this poor communication structure are the same ones which have reputations for notoriously tyrannical CEOs. Maybe they’re not tyrants… maybe they’re surrounded by poor communicators. Or maybe they are tyrants. I can’t tell from where I’m sitting.

The good news is that if you ever have to deliver a mandate without the facts to back it up, you less likely to pull a rookie mistake and land your Home Grown Mandate without the reasoning… the justification. You’re also not going to forget to Deliver (Again) because you know that each time you stand in front of your team, trying to be a leader, they are watching and they are listening. They want to know if you deserve the title of manager.

What To Do When You're Screwed

Cabel Sasser of Panic dropped a shirt off with me shortly before my first presentation at WWDC.

For those of you still using Lynx, the shirt reads, “Hi, I make macintosh software.”

While Jimmy Eats World was ripping the tunes at the WWDC campus bash, I proudly wore the aforementioned shirt all over the campus. Co-workers quickly pointed out, “You don’t make software anymore… you tell others to make software.”

That’s right.

I do.

Let’s get started.

You’re a manager now. Congratulations. Either you sucked at programming and wanted to try a different influence avenue or you’re fed up with every other manger you’ve worked for and now you’re going to REALLY GOING TO SHOW US how it’s done.

I’m here to help.

Your first five years as a manager are going to be full of lessons galore. Lesson #1 begins the moment someone asks you a question and you realize they’re asking you not because you actually know the answer, but because the term manager is in your title and they’ll believe any reasonable answer. Some folks call that power, I call it responsibility.

There are other lessons, as well. There’s the big three: hire, fire, and layoff. All of those are a nice kick in the teeth that’ll be the source of significant insomnia. There’s the little stuff, too. You’ll find yourself saying “We” a lot. You’ll notice you’re repeating yourself… saying the exactly same thing to twelve different people. Some of it’s entertaining, some of it’s dull, but it none of it compares to when you’re Screwed.

The state of being screwed is unique. You know when things are going smoothly because you can arrive in the morning and quietly sip your hot beverage until your first meeting at 11am. Screwed is the oppposite. Screwed is being accosted the moment you walk out of the elevator and being unable to even check your mail… until Winter.

Screwed is mental paralysis.

Screwed is career panic.

Screwed is also an opportunity to hit it out of the park. Overcoming screwed will give you confidence, experience, and respect, but you need to figure out how screwed you actually are and then then figure out and how to fix it. If you aren’t interested in unscrewing yourself, I’d suggest this article is not for you. I’m assuming you have passion regarding your professional career. You want to do more. You want make more money and, if it all works out well, you want to change the world.

Maybe I haven’t been kicked in the shins enough, but it baffles me when I run into folks who are coasting through life. Doing the bare minimum to get by and… enjoying it? What exactly are you enjoying? Hey, maybe your day job isn’t your gig, but I like mine, so let’s begin:

#1) I’m Missing A Document and People are Yelling at Me
Screwedness: Low

Early on the product development process, everyone is talking about writing it down. Marketing specifications, engineering specifications… specs, specs, specs. Milestones are often constructed around these specifications, but, usually, these milestones come and go and no one really gets fussy about missing or incomplete specifications. That’s the good news.

The absence of a particular document really isn’t that relevant to your screwedness. The real question is “Who is asking for said specification and why?”

If the requestor is someone who has a legitimate need for the information, your potential screw-i-tude is high. Someone, somewhere is not able to do their job and that means someone could fail in their work and that’s bad because they’re going to be pissed off and pointing at you.

A tip: Don’t confuse the request for information as a request for a complete answer. You completionists out there do this a lot. “I must answer the question thoroughly and completely; therefore, I must start by selecting a template for the information that best structures my response and BLAH BLAH BLAH”… two weeks later and the requestor has moved on. You have officially missed your window to sound like you know what you’re talking about and, guess what, you’ve also been pegged as hard to work with / unreliable. Way to go.

Larger organizations really believe they need to document more and they’re right. Communication in big organizations is tricky because everyone’s got an opinion and you never know who is going to have a bright idea. Big company policy on requiring documentation is furthered by layers of management struggling to ascertain/measure what is actually going on in large groups of people. (See: Status Reports Must Die)

If you’re feeling screwed by the absence of some important document, again, look at who is giving you that screwed feeling and ask yourself, “Is this an honest request for facts or a management boondoggle?” If the answer is facts then face-to-face communication is always the way to go especially if time is of the essence.

This section reads like I’m anti-documentation which is silly because HELLO I WRITE A WEBLOG. Remember the context of this column, “When you’re screwed…”. I’m talking about situtations when it appears the sky is falling and you need to move quickly. I could easily argue that diligent and frequent documentation is a handy way to avoid sky-falling-situations because writing stuff down is a great way to make information scale… because you don’t.

#2) A Significant Development Tool Does Not Exist on My Team
Screwedness: Varies by tool

There are an endless pile of tools engineers are fond of using in their development process, but there are only four that they really need:

• Editor
• Compiler
• Version control
• Bug tracking

I’ve never seen any engineering organization that hasn’t had some form of an editor and compiler, but I’ve been shocked to find both version control and bug tracking missing when I’ve walked in the door.

If you ever find yourself in this situation, your first job… before you even sit down at your desk… is to get these tools in place and in use or you and your organization will be forever screwed. Any engineering organization with more than two people will fall flat on it’s face as soon as the product development process gains any sort of momentum unless version control and bug tracking are in use.

These tools empower engineers by allowing the entire team to:

• Collaborate without stepping on each others toes. You do this, I’ll do that.
• Be accountable for their work. Who’s got that checked out? Who’s bug is this anyway?
• Measure their work. How many bugs do I have? How about you?
• Remember what they did. Uh, who the hell checked in this crap?

You’ll find early on in your management stint that main reason people make the trek to your office is because they need conflict resolution. Once the conflict participants stop yelling, you need to get them looking at facts because facts will ground them and grounded means less yelling. All of the tools I describe above are excellent repostiories of cold hard facts and that can help.

#3) I Can’t Stand My Product/Program Manager or They Plain Don’t Exist
Screwedness: Medium

As an engineering manager, you need to have two significant peers. First, you have a product manager… marketing. This person represents your conduit to your customer and their needs. Second, you have your program manager. This is your process and communication czar.

The program manager role is a bit harder to define because most engineering managers confuse a program manager’s role with their own. A program manager owns the entire process of shipping a product. Think of it like this, you, the engineering manager, hand a DVD with your final product to the program manager and they make sure it shows up in Fry’s in the right box. Don’t think that isn’t a huge amount of work because it is.

Again, both product and program managers are information brokers. For the product manager, they represent the customers needs… they tell you what the customer wants and you build it. Once you’re done, they tell you how it went. The program manager’s information is organizational. For any given question, they know the answer or know who to ask. Good ones are also process wienies which means things just don’t fall through the cracks around them.

Program Manager Sidebar: My strong belief in the role of program manager comes from first hand screwedness. My start-up was twenty folks when I arrived as the first engineering manager. Over the coming two years, we grew to 250 people where I was managing three product lines. The executive management team created the program office around that time and I was immediately suspect. “What do these boobs do? Take meeting notes? Jesus, what a waste.” Wrong wrong wrong. Good program managers are detail drivers. They handle the piles of minutia surrounding a release and you’ll be shocked the amount of time they’ll save the average engineering manager.

If you’re unable to work with these co-workers or if they just don’t exist, you’re pretty much at the same state of screwedness. You’re going to have to do their jobs for them and that means less time to actually be an engineering manager. This isn’t going to feel like screwed because you’ll be busy, but you are, bit by bit, cheating your team and your product out your time while you making sure the box art looks right.

Of the two, a missing or moronic product manager is probably more of an issue since their data affects the work of your entire team. You’ll likely make things worse when, if pressed for time, you declare, “Well, I know what’s best for the customer.” Again, wrong. Unless your product is targetted at software engineering managers then it’s unlikely your opinion is relevant. Sorry.

#4) My Product is No Where Near Done
Screwedness: Less than you think (hopefully)

Let’s first remember that product development team loses their minds the last month of any significant product development cycle. Really. They’re insane. They’ve been staring at this damned product for so long that they’ve developed a serious emotional attachment with the bits and that means irrational, goofy behavior that is not based on reality.

This is you. Mr. Insane Engineering Manager. It’s two weeks until your product ships and you are sure there is no way you’re going to make it. Your claim is, “The product is crap”

Now, there are two possibilities both of which are equally possible. First, you might be too close to the product to make a quality judgement. Your initimacy with your product has clouded your judgement and what you’d consider ready for prime time has nothing to do with what a customer would be happy with it. If, in a moment of lucidity, you realize that this the situation you’re in, it’s best to find a person/party who’s judgement you trust and get a sanity check. You’re instinct will be to go to your QA organization, but they’re likely equally in love with the product and probably more wacked about quality than you.

Maybe your boss? Maybe another engineering manager? I don’t know who, but it’s got to be someone who has not spent the last three months living and breathing this product that’s NEVER GOING TO SHIP. When you do find a designated sane person, they should ask questions like this:

1. Are the features done? How done? Are they testable?
2. How many bugs are left?
3. How many bugs are you fixing on a daily basis?
4. How many bugs are you willing to ship with?
5. What’s your bug deferral criteria?
6. What’s your update strategy?

This sane person’s job is not to decide for you. Their job is to be neutral and to help you frame your decision by asking great questions. As a rookie manager, you’re not going to seek external input because you’ll think asking for help is a sign of weakness and, boy, are you wrong. Asking for help of team members allows these folks to apply their unique experience to whatever the problem might be and that’s how you make better decisions while also building a stronger team. Asking for help is a big deal. Do it. Often.

That’s situation #1… getting a second opinion. This leads us to situation #2 which is, you’re right… your product is nowhere near ready for customers and you’re fourteen working days from shipping. You and your team are charging forward to the ship date, but most everyone is shaking their heads slowly and murmuring, “It’s not ready”.

And it’s not. No need to get a second opinion. You’re still finishing features. QA is sufficiently pissed off and your program manager is crying in his/her office.

Yes, it’s really not ready.

As an individual contributor, your job is to bitch about the situation. I mean that in a good way. Bitching is one way to conveying data and if your manager is listening, they’ll register it as such. Problem is, you’re the manager and it’s now YOUR JOB to make initiate a course correction because late is better than crap.

If this is your first ever course correction, you’re going to believe you’re more screwed than you are. Here’s the truth: Most everyone believes that engineering is lying when they propose a schedule. It’s what fancy word talkers call a truism. If engineering says it’s going to take a month, it’ll probably take three. Ok, maybe lying is a bit strong. We’re actually not lying, but we’re doing the best we can, I swear. We honestly don’t know how long it’s going to take to finish that feature until we’re halfway done.

Organizations insulate themselves in different ways against the lack of engineering certainty. Some product groups build in slip time. Others have mysteriously named milestones POST ship which are the actual ship dates. The point is: If this the first proposed slip for any given product, you’re going to be pleasantly surprised when the product team says, “How much time do you need?” Didn’t know you were playing poker did you? Well, you are.

DISCLAIMER: If you’re interested in building any sort of credibility in your organization, I suggest that slipping your product late in the game is just bad PR. Any good engineering manager + program manager team is going to build in feature and schedule checkpoints where mid-game adjustments are made that give everyone higher confidence in a final schedule. Last minute schedule changes violates Rule #3 of Rands Management No No’s: “No surprises”.

#5) My Company/Job Sucks or Is About To Suck
Screwedness: High

True story. In the early 90s, Borland was taking it on the chin from Microsoft. Borland’s big transition of their office applications to Windows was going abysmally. The Microsoft monopoly was in full force… they bundled their first version of the Office suite and were underpricing the competition. Good-bye Quattro Pro, Paradox, and dBase.

After years of expansion and a move into a (still) amazing campus, Borland was about to implode and I was aware of this. That’s the first step to get yourself unscrewed in this situation… detection… knowing the ship is sinking even though those execs continue to sound eternally optimistic in those all hands meetings. Of course they sound positive, if the rank and file universally believe the sky is falling, those all hands meetings will become utterly devoid of hands.

What’d I do? I jumped ship. I took my engineering title and moved up the peninsula to a now defunct database company. Problem was, the new company was in much worse shape than Borland having imploded about a year earlier. I didn’t know this until my hiring manager who had portrayed portrait of enthusiasm and vision was gone one month after I started. I was suddenly debugging build systems and drinking really bad coffee with a bunch of chronically depressed database developers.

Ooops.

It’s obvious, but there are two parts to getting descrewed when your company sucks. First, detection. There are people still at Borland who, to this very day, are still bitching about that company the same way they were over a decade ago. Let’s call them faux-Bitchers because for all their bitching, they’re never going to do anything about it because bitching about, apparently, is enough.

You are not faux-Bitcher because you’re still with me. You want to do something about your screwedness. You want to make an upwardly mobile move. You want to go somewhere where you’re:

1. Getting a raise
2. Getting a promotion
3. Getting to do something that interests you
4. Working for a company that doesn’t suck

In my post-Borland move, I succeeded in A and B, but I blew D… and, it later turned out, C. It was my worst career transition ever and it took me a year to get back to a place that I felt I was moving forward. Good managers keep their teams, their products, and their careers full of velocity.

Velocity.

That’s a better term than upward mobility. Constant forward momentum.

How you are going to achieve your own personal velocity is your own deal. My apparently endless stream of management advice is just that… advice. What you really want is my experience, but you can’t have it because there is only one way to get it… you’ve got to put yourself a situation that allows you to get screwed. When you’re deep in it and terrified, maybe some useful acquired advice will pop into your mind or maybe you’ll construct more elegant solution. Either way, you’ll come out the other side moving faster… or maybe slower.

Healthy Tension

As a manager in any software engineering organization, you’re going to be subject to a lot of interpersonal angst amongst the team members. You’ll be walking to lunch and Engineer A is going to be ranting and raving about Engineer B on another team…

“Man that guy bugs me. Have you seen his code? Wow! Unreadable. Totally incoherent. “

9 times out of 10 if you put Engineer A and Engineer B in the same room, you’d be unable to discern that there was an actual issue because they’d treat each other professionally and with courtesy.

Fact is, the angst was faux angst and while there may be an issue there, your primary job was to sit there and be a sounding board. The issue will often resolve itself or just be that… an issue. Where you’re going to need to get involved is where the angst is real and potent and, well, as emotionally charged as I’ve ever seen in hi-tech… the bug database.

Repeating for clarity: A bug database is where people truly develop hate in software engineering organization.

It’s always during the last few weeks of the development when the bugs become the one and only metric the organization is watching to see if the product is going to ship. QA knows this. Engineering knows this. Their days are centered around reloading database queries which show them how many bugs are currently on their plate. More is bad, less is good. Zero is best.

The reason the hate erupts between QA and Engineering is because most software engineering organizations create a healthy tension between QA and Engineering. The tension is based on a simple idea:

• Engineers create code which makes a product.
• QA confirms the code is written well (which it often is not).

These are contradictory goals. Let’s simplify them into declarative statements:

Engineering: We believe we have done our job.
QA: Uh, no you’ve haven’t.

Of course Engineering is going to want to give QA a poke in the nose. QA is telling Engineering they’ve done their job poorly and what wants to admit they screwed up?

For much of the cycle, everyone is so busy designing and developing the product that not much attention gets paid to the bug database. That changes as soon as a graph gets posted on someone’s door which shows the bug arrival rate versus the bug fix rate. The race is on… who is going to win? More fixes or more bugs?

The bug database becomes the plan of record for product and all hell breaks loose because, well, everyone is trying to do their job and it turns out the bug database is the last place they should do it.

If you’ve spent time in a bug database, you know the precise emotion I’m talking about. Read this bug report and reflect:

Bug #52392 - App crashes (Severity 1)

Steps to Reproduce:

1) Click on the application (Build #45)
2) Application crashes

Expected Result:

The application should not crash

Let’s assume this is the first bug report you’ve ever received from this QA person. You’re going to cut them some slack, you respond with:

Engineering: Thanks for the report. Could you reproduce this and send me a crash log?

Three hours later and you receive the bug back with the following information:

QA: Just click on the application and you’ll see this for yourself.

Grrrrrrrrrr. Ok, now your pissed. Who is this boob? Doesn’t he/she realize that if the application DIDN’T EVEN RUN that it would have never even gotten out the build team? And even if it did, every single engineer on your floor would be bitching and moaning about a broken build. WHAT A DUMB ASS.

Can you feel it? The blind rage over a text entry in a database? Boy, are you tense. Take a break and let’s see what happened.

See, the data you need in this bug wasn’t in the steps to reproduce. The data was in a subsection of the bug that you never look at. This tester is a wireless tester and it turns out your application does crash in a wireless set-up and he’s the only who does wireless testing in the building.

Why in the world do you want to hate this guy? Just because he’s doing his job? No… you want this guy beaten because it appears from the bug report that he’s an arrogant twit, but the fact of the matter is, you’re a lazy bug reader.

This is one of a million unfortunate situations that happens in late in a product cycle. Yes, there are truly twits out there (in both QA and Engineering) that should be poked in the nose. Still, when I’m forced to triage the aftermath of a bug war, it’s almost always individuals trying to resolve conflict via a bug rather than getting their butt out of their seat, walking over to the other individual involved, and acting like a human being.

Anyone who has had significant experience interacting with other people via email, instant messaging, IRC… whatever… you know that context is lost when you translate to text. You know that when you really want to understand what someone is trying to say in email, you pick up the phone and ask, “Um, what the hell are you talking about?”

Yes, the healthy tension must exist between QA and Engineer because they do have conflicting goals. Your job as an engineering manager who doesn’t want their team poking each other in the nose is to remind your team that, first, if you’re grinding your teeth in your office as you’re reading a bug, I guarantee, I promise, I swear that you are missing some essential piece of revealing data that is just short walk away. Second, both teams, QA and Engineering, have the same goal. They must ship product.

Heinous

You and your software development team are close. So close. Just a few more bugs and you’re ready to get those bits out there. You can taste it, but… the bugs keep showing up. Five in the morning. Ten in the afternoon. Oh shit, fifteen more during the weekend. Each day… anything more than zero is just bad news.

Not. Shipping. Yet.

One word is going to help you. One word is going to turn the corner from DOING to DONE. That word is Heinous… and Heinous wants to help.

Let’s back up.

To understand the value of a single word, you first need to come to terms with where your brain is at late in the product ship cycle.

You are insane.

It’s true. You are nuts.

I’ll explain, but first we need to be clear about exactly where we’re at in the product cycle. This isn’t the last month of work… this isn’t the last big push. This is the culmination of a huge amount of work done by a handful of people who have been bleeding from the fingertips for the last month.

You and your team, for as long as can you remember, have been living and breathing “the product”. You’ve spent months designing it and months/years developing it, so it’s hard to figure out where you stop and the product begins.

This frame of mind, this intense relationship with a body of code, is not conducive to actually shipping product because you are blinded by your devotion to the product. You want to see your product successful because of what you and your team have sacrificed and OF COURSE you are imminently qualified to fix what ails your product…

Bugs.

The bane of your existence.

You will kill… kill them all because they threaten you and your product.

See? You’re certifiable.

I exaggerate. Your shipping experience may not have been as intense as this, but I assure you if you’ve spent more than six months on a code base that your collective mental panties are in a bunch.

You need Heinous.

Heinous means bad. Really bad. Horrible sky-is-falling bad. Grossly wicked. Jack the Ripper bad. Are you getting this? Good.

Heinous is the word to describe the type of bug you will not ship with. As a responsible parent for your product, you think you will ship with no bad bugs and that’s where you’re loopy. You’re going to ship with tons of bad bugs. More than you’ll be comfortable with. You’re, however, not going to ship with Heinous bugs because these are the bugs which, if found AFTER YOU SHIP, would stop the presses. People would run around the building screaming. Much money would be lost and heads would roll.

I’m not talking crashes… I’m talking massive data loss… horrible operating system hangs… exploding computers. I’m talking Heinous.

Now, you completionists out there are having a hissy fit right now because I’m suggesting that software should ship with bugs and that offends your purist sensibilities. That’s fine. I expect my resident completionists to hold the perfection bar as high as they are physically able, but completionists don’t ship software. Incrementalists do because incrementalists know that better is the enemy of done.

Still, whether you are an incrementalist or completionist, you both need Heinous. Everyone needs a cue to understand that the time of fixing bugs is over and the time of shipping product has begun.

Here’s a hypothetical recreation of a bug triage meeting from my start-up. It’s me (engineering director), VP of Professional Services, Director of Quality, and our Product Manager. We’re going down the list of new bugs which arrived over night… five days until shipping:

Me: “Bug 9744. Moving applicant back to interview state creates garbled text.”

QA: “There’s a workaround, I’m not sweating it.”

ProServ: “There will be training impact, can we get this fixed?”

Me: “It’s about a day of work.”

Product Manager: “This will reflect poorly on us in the press.”

Me: “It’s a day of engineering and a QA slip.”

QA: “We can test it in our current schedule.”

Me: “No you can’t. It’s a significant change… blah blah blah.”

I have just wasted five seconds of your life that you will never get back. Now, multiply this scenario by the other twelve bugs that showed up that night and you’ve got the makings of a nice product slip. Let’s look at the same meeting now enhanced with Heinous:

Me: “Bug 9744: Moving applicant back to interview state creates garbled text. Is this Heinous?”

Them: “No.”

Me: “Bug 9745…”

See? Everyone gets it. Everyone knows that when Heinous is being thrown around, it means WE REALLY REALLY NEED TO SHIP THIS DAMN THING. Maybe it’s a date driven schedule or maybe it’s a strategic ship date. Who knows? You’ve got to get those bits moving.

Some rules around Heinous:

- You must make sure everyone is aware of the definition of Heinous. Not repeating yourself means you are saving time.
- You may slightly alter your definition of Heinous and that’s fine, but use the definition consistently. Don’t tweak it to your own personal agenda — you will lose credibility and no one will listen to you next time around.
- Don’t use Heinous until you need it. There are four or five big freak-outs in any product cycle before Heinous needs to come into play. If you use it early and then non-Heinous bugs start sneaking in, you’ve blown it and devalued Heinous for everyone. Don’t.

Anyone who tells you that developing software is hard is absolutely 100% wrong. The hard part of developing software is actually shipping the product out the door. It’s not designing or coding or testing a product that is tricky, it’s just that everyone on and off the product team has a damned opinion about this or that or how fast or how slow or how it looks or how it feels. Your job until Heinous arrives is to carefully aggregate, listen to, and act on those opinions because, chances are, someone is smarter than you. These opinions will give you a better product.

With Heinous, the discussion is over. The product is done.

Agenda Detection

I hate meetings.

Everyone hates them because we’ve all been to so many that have sucked so badly that we now walk into a conference room, sit down… arms folded, and think, “Ok, how long until this one is going to suck?”

And then it does. Time is wasted. Hot air is created. Silent frustrations are confirmed while historic hatred of managers is furthered.

There is a basic skill you need whenever you walk into a meeting which has suck potential. This skill is important in the case that you are a participant or the person running the meeting. The skill is called Agenda Detection.

Simply put, Agenda Detection is the ability to discern:

1. Typical meetings roles and how meeting participants assume them
2. Explanation of what these distinct meetings roles want out of a meeting
3. How to use this understanding to get the hell out of the meeting as quickly as possible.

If you’ve ever been frustrated in a meeting — if you’ve sat there wondering why in the world these people, these managers, who are paid the big bucks to move the company along simply can’t do or say the painfully obvious then keep reading.

The first step in getting out of a meeting is to identify what kind of meeting you’re in. A meeting agenda would help, but as most meetings proceed without one, you’re on your own. Chances are, you’re either in a informational meeting or a conflict resolution meeting.

At informational meetings, big surprise, information is passed on. Think your favorite quarterly all-hands meeting, staff meetings… any meeting where there’s a standing assumed agenda. There are two kinds of participants in these meetings: talkers and listeners.

Roles and agendas in these meetings are simple. Talkers are talking and listeners are listening. Get it? There is no problem to be solved other than the transmission of information… that’s it. The quicker it happens, the sooner everyone is back to work.

You can quickly identify those folks who don’t get this. They’re the wack jobs who always ask the same (or random) question during an all hands with the hope that simply by asking, they’re going to change something. It’s a noble act… speaking your mind in front of all your peers. It’s a waste of time. This is an informational meeting, people. The talkers are here to pass on whatever organization knowledge they need to so as to prevent a rebellion. When the wack job speaks up, everyone who gets the nature of the meeting is thinking, “Ok, another useless question which is going to keep me here longer. Crap.”

I’m not saying that rocking the boat during the required Q&A session is not feasible in these meetings, it’s just not efficient. Folks are there to nod, not solve problems. Where the wack job should be speaking up is at our other class of meeting, conflict resolution… that’s where they could influence folks because people go to these meetings to solve problems.

At a conflict resolution meeting, some problem needs to be solved. Apparently, it could not be resolved via email, instant messaging, or hallway conversations, so some brihg tfellow decided to waste some more time in a face to face meeting where the bandwidth is high and the time wastage is significant.

Agenda detection in the conflict resolution meeting is more complex. To see it in action, let’s create a meeting:

4pm, this Tuesday. You, Joe Sr. Engineer, two other random engineers, one product management person, and a program manager. The program manager called the meeting to solve a problem. See, the Sales folks sold something that your company does not make. You’re here to explain how much it’d cost to build this thing that you’ve never built before but that’s already been sold. Been here? Thought so.

Agenda detection starts when by first classifying the players. There are two major types that you need to identify: Players and Pawns. The simple distinction between Players and Pawns is that Players want something out of the meeting. This is their incentive to participate. They’ll be leaning forward, actively nodding, and barely able to hold themselves back from spilling their agenda all over the table.

Pawns are either silent or instruments of running the meeting — in any case, they’re adding very little to the meeting and can be removed from consideration as a means of getting out of the meeting. The term Pawns is not intended to be derogatory… Pawns very well might be running your company, but in meetings, they just don’t contribute… it’s not their key skill.

Bucketing of Players and Pawns is simple, you can do it with the attendee list and a bit of organization knowledge. Let’s try it with our hypothetical meeting above.

First, you can assume all the engineers are players — they’ve got technical knowledge they may throw on the table otherwise why were they invited? The product management person is also a player as they represent sales folks in this meeting. The program manager is a pawn… they’ll make sure action items are recorded and that the meeting ends on time.

MEETING BAIL TIP #1: If you’re sitting in a meeting where you are unable to identify unable any Players, get the hell out. This is a waste of your time. These are meetings traditionally called by wind bags who like to hear themselves talk, but hold no real influence over the organization/product/whatever. Unfortunately, if you’re new to a group, you need to get burned by the wind bags a few times before you learn to avoid this totally fucking useless meetings. It’s tough being the new guy.

The next step in agenda detection now kicks in as we look at the Players. This is when you figure out each Player’s position relative to the issue on the table. For whatever that issue is, there are two subclasses of Players: the Pros and the Cons.

The Pros are the players who are currently on the winning side of the issue. They’re getting what they want and are not incented to negotiate. Heck, they don’t even have to be there… they’re just here to see the Cons squirm. Yet, they are there, they’re at least willing to listen to the Cons, right? Maybe.

The Cons, clearly, are the ones who are being screwed. They’re likely the ones who yelled loudly enough to get the meeting set-up in the first place. Cons are usually easy to pick out because they’re expressing some degree of pissed-off-ed-ness.

MEETING BAIL TIP #2: Like our Player requirement, both Pros and Cons must be represented for any progress to occur otherwise you’re just going to talk and talk and talk. You’re guaranteed the Cons are going to be present because they’re the ones who are screaming and shouting. If you want the meeting to actually produce something useful, the Pros must be represented. The specific Pro does not need to be in the building, but they must have designated a proxy otherwise the Cons are going to bitch, heads will nod, and nothing will happen.

Let’s take a stab at identifying the Pros and Cons in our hypothetical meeting.

In the example above, it’s clearly engineering who is being asked to build a product THAT DOES NOT EXIST. They’re pissed and they’ve called this meeting to quantify this frustration. Hello Cons.

As we’ve already identified our program manager as a Pawn, we can only assume that our product manager is the Pro. But wait, now you’re in this meeting and she sounds like an engineer. “Those god damned sales folks. What the hell are they thinking? This is the last time blah blah blah…”

Wait, our product manager appears to be a Con? Does this means Rands thinks I should pull the rip cord and get the hell out? No, your product manager is the Pro… she’s just bright. A common tactic of a good Pro is to not acknowledge that they’re the Pro. This means that they don’t have to actually take the heat for whatever the conflict is. The real Pros aren’t in the room — the real Pros, in this example, are the sales folks who cut the deal to sell the product that doesn’t exist — except they’re out in the field cutting more unachievable deals. The product manager is attempting to fake out the engineers in the room by saying, “Hey, this is a tough problem that THEY have put US in… what are WE going to do?” Brilliant bait and switch, no? Don’t sweat it. They make less than you.

The stage is set. Our Pawns have been filtered out. Our sneaky Pro is nodding.. placating with her feigned commiseration, the Cons are yelling and, yes, you’re still in the meeting.

Believe it or not, the hard part is done.

If you’ve paid attention, you’ve got a pretty good map of who is who, where the whos are… now all you need to do is figure out what the whos want. The Pawns don’t want anything — they were just happy to be invited. The Pros are there to show off their complete and utter ownership of the issue… they’ll leave whenever, the sooner the better.

So the reason you are sitting there is the Cons. What is it that they want?

Stop. You’ve got some meeting in mind, some horrible meeting where the issue is so complex that there is no way the simple identification process I described could apply. Wrong. Your jumping to solve the issue and there is where everyone fucks this up. Who cares about the issue? Do you know who matters in whatever horrible meeting your sitting in? Did you take the time to identify the people who actually care? The ones who can make a difference? If you haven’t then you deserve every useless minute of that meeting.

I am convinced that a majority of the meetings on this planet go long and do less because the people sitting around the table simply do not figure who the hell they’re talking to and what they want.

Yes, the Cons do want something. You’re going to meet their needs in order to get out the door and their needs are simple… so simple you’re going to laugh. The Cons need a plan. Some assurances there is a plan which is going to somehow address whatever the issue is. Doesn’t matter if that plan comes from the Pawn, the Player, the Pro, the Con… someone needs to synthesize everything into constructive next steps, communicate that TO the Cons, and you’re done. You’re out the door.

Doesn’t need to be a great plan or a honest one or a complete one. Cons will not let you out of that meeting until there is the perception of forward progress (“a plan”). If you’ve scheduled a hour and that hour is up, you’re thinking, “Well, that’s one way out the door”. Again, incorrect, because the Cons are returning to their desks and scheduling a follow-up meeting where the organizational ineptitude is going to continue.

MEETING BAIL TIP #3: You very well might have the requisite Players & Pros/Cons, but, then again, you might have too many. If it’s thirty minutes in and you still can’t figure out what the issue is, it’s time to go… too many issues. Someone who cares more than you needs to distill this chaos down to a coherent statement so the Pros/Cons can argue about one thing.

Meetings are always going to be inefficient because language is hard. Getting folks in the same group, with the same organizational accent to talk coherently to each other is hard enough. Meetings give us the opportunity to include other organizations with other accents. This makes the language chaos complete, but, now, you don’t care. You don’t need to know what they’re saying because with Agenda Detection, you can figure out what they want, get it for them, and get the hell out.

Status Reports 2.0

At a start-up, there are two organizational inflection points which drastically change communication within the organization. The first change occurs around fifty or so people — this is the moment when, if you’re an early employee, that you first see someone in he hallway that you do not recognize.

This is troubling to you because, until that point, not only knew everyone on a first name basis, but you also knew what they were about… what they were responsible for… what floated their boat. Now, there’s an unknown quantity in the building.

This awkward, but necessary evolution of the organization, passes. You accept the fact the company is growing and you decide to focus your attention just on your group… who cares what those schmoes over in the support group are doing, anyhow? You’ve got an engineering organization to build.

The second organization inflection point happens somewhere around two hundred… two hundred and fifty. The problems identified during the first inflection point are serious problems now. Fiefdoms have been created in your organization and they’re not talking to each other. What made your organization great early on, great communication, is still going on.. it’s just going on inside of each of your organizations and not across them.

Executives in these larger organizations may be the first to recognize this when they’re meeting with these different organizations and get the impression these individuals teams don’t work for the same company.

So, the executives panic. They have an offsite where they talking about cross-functional communication and teamwork. They come back, promote some would-be-holistics to be Directors to improve communication, reorganize the company, and then… they do it… they curse the organization with busy work… busy work in the form of Status Reports.

I’ve managed a variety of different sized organizations. In the larger ones, inevitably, I’ve had a meeting with my managers where I’ve needed to explain what my Status Report policy is. I’ve always started this conversation with this same preface, “I’m sorry, but we’ve got to do Status Reports.”

Why am I apologizing? Clear communication is a good thing and status reports are just good, clean communication, right? No, they’re not. The reason I’m apologizing is because by instituting or supporting a Status Report policy, I’m admitting, “I do not have a better solution to facilitating good communication than busy work in the form of Status Reports. Sorry. I’m pathetic.”

The idea of Status Reports is not a bad one. Generally, I ask for the following information on a weekly basis. Highlight, low lights, and any open issues. Pretty simple. Think of it as a weekly litmus test. The first few weeks with a new group, I tend to get stellar Status Reports from the team. Lots of detail… lots of energy… lots of content. It’s clear the manager and the team spent time on the report.

Two months later, Dullsville. The very same people who were generating content rich Status Reports are now sending bullet lists that really don’t change on a weekly basis. I stop reading them, they stop writing them, and we’re back in the Land of Poor Communication where we perpetuate the fact that everyone hates Status Reports.

This needs to be fixed.

To me, their are two major consumers who need Status Reports. The first consumers are the executives/overseers/managers. This is your senior management crowd who want a high level overview of where all that money is going. You want to keep this group in the loop because they sign the checks, they can be very good at discerning warning signs from seemingly vanilla Status Reports, and they also usually are big influencers on strategy… this is key when you want them on board when you’re proposing that two month slip to improve quality.

Due to the fact these folks see a lot of Stats Reports, there’s a requirement for the data to be somewhat normalized via a familiar template otherwise they’re going to get frustrated spending their time figuring out what information is being conveyed rather than acting on it.

The other major consumer for Status Reports is, well, everyone else in the company. Actually, let me rephrase, the other consumer is everyone else in the company who wants to read your status report. I’ll explain…

Right now, you probably send your status report to some group of people or a mailing list which goes “to the right people”. The definition of the “right people” is likely based on role in the organization… the managers… the leads… whoever is supposed to have cross-functional visibility.

Here’s the problem with this group you’ve selected.

Let’s say you’ve had an open issue on your status report for four weeks now. It’s gone on long enough that you manager is starting to bring the issue up at your 1:1 and she’s getting frustrated that your answer to “What progress has there been?” is SHRUG. The correct answer to your four week open issue is sitting in the head of JoeBlow Engineer who sits nowhere near you. He is completely outside of your management food chain and he can save your weeks of effort and possible executive embarrassment. How in the world are you going to get to this guy?

Sure, if you’ve got a solid list of recipients for your Status Report, there’s a good chance that someone might make the connection between your Open Issue and JoeBlow, but, chances are, that manager has grown jaded about Status Reports JUST LIKE YOU.

You’re waiting for the punch line here, you think I’ve got some solution and, well, I don’t. What I do have is a rough knowledge of many of the emerging information management tools and I know there is a solution which:

- Makes it easy/attractive for larger organizations to share their information
- Provides a facility to publish scheduled structured reports to executive-types

Let us first talk about two tools:

WIKIS

Wikis provide a solid, flexible backbone for information gathering and distribution, but they are geek. Average computer users will not find them accessible. This means that any solution based on Wiki technology will mostly benefit engineering. I’m ok with that.

Wikis intentially don’t provide structure which means chaos rules. That’s great for a random mix of evolving information, but, at the end of the week, someone has to generate a Status Report and that person’s life will be easier if they don’t have to do a damned thing.

My gut feeling is that while Wikis are a great tool for organic information evolution, they’re not going to play nice in the Status Report world. Not only because of their lack of structure, but I believe the content would be biased the moment those who provided content discovered the Wiki was being pruned for Status Report data.

WEBLOGS

I can see three possible implementations here:

1) Everyone on the team has a weblog
2) “Leaders” have weblogs
3) Project or aggregate weblogs

Weblogs don’t have the level of collobartion has a Wiki, but they can be more structured. Plus, a variety of linking technologies varying from simple links to TrackBack technology provide some of the interconnectiveness that Wiki’s do so well.

A big issue with the weblog is initiating that first conversation within it that doesn’t sound like, “Hey guys, we’ve got a team weblog now and, well, speak up so I have to do less work on status reports.”

There needs to be some creative incentive for individuals to write stuff down. For the Wiki, there is the promise that if you write it down, maybe you can avoid future lame redundant questions. For the weblog, the timely conversational style of the medium keeps the content focused on news of the moment and that’s really the question; is news of the moment interesting to an engineering organization?

What I’m curious about is if anyone has had any success using web-based collaboration tools as a means of augmenting or replacing status reports. I know Wikis have successfully emerged as semi-structured information repositories… have they evolved into anything? How in the world can I get out of writing Status Reports?

Thingdom

My all time favorite line from The West Wing is, “We’ve got a thing.” There are variations of this favorite line which all revolve around the same word. “Is this going to be a thing?”, “Have you heard about the thing?”, “So, here’s the thing.”

I immediately applied a generous helping of Thingdom to my work day. My staff meetings are now laced with blissfully vague references like “It’s too early to tell, but we may have a thing” or “She’s working on the thing and there is no telling when she’ll be done.”

There are two camps when it comes to Thingdom. Camp #1 has stopped reading this article already because they’ve grown frustrated with pool of ambiguity this article is swimming in. RANDS HAS BLOWN A GASKET. Camp #2… ah… Camp #2… what I love about Camp #2 is that you precisely know what I’m talking about and I have yet to actually say anything.

Aaaaaaaaaaaaaaaaaaah. Thingdom.

Thingdom when used in the White House, your work, or your home is a state of mind. The word itself is not important. What is important that it’s used in a context rich environment — that’s thingdom nirvana. I’ll explain.

It’s your staff meeting. You’re running down your list of interesting data points for your team. Your hit the tenth item and realize that it’s important to dwell on this item. For this example, it is not important what the item is, it’s important that you are able to recognize/prioritizes its value. So, you say, “I think we’re going have a thing here.”

What have you said? Content-wise, not a helluva lot. Context-wise, well, it depends on how well your team communicates. If you say, “We’ve got a thing” and everyone immediately snaps out of the staff-meeting-glaze, you’ve got a context-rich team environment. The team heard the boss identify the thing as a thingable thing and they’re ready to roll.

However, if the team stared blankly at you and each other when you landed the thing, well, I’m sorry… you’re going to have to spell out the consequences, piece by piece, to your team if they don’t get started on thinging that thing. Maybe the lesson will improve their thingdom identification skills. Maybe it won’t.

Thing-enabled teams are more efficient. They better understand sub text, nuance, politics, soft skills… the list of skills is extensive and in my years of managing people, I’ve found it’s a skill set that no one can teach. When I interview, I’m looking for the thing. When I meet you in a bar, I looking for the thing. On Sunday morning, when I’m surfing weblogs, it’s all about thing.

Inwards, Outwards, and Holistics

As already discussed, Managers are not evil. They’re often just stuck in translation hell where they need to say one thing in one way to one team and say the EXACT same thing to another team in a different way. This constant verbal tapdancing looks sketchy to you, the Average Joe, and you start to wonder, “Hey what does that guy do all do in those meetings anyway? Do he do any ACTUAL WORK?”

Yes.

There are all sorts of intimidating titles surrounding the management caste. Engineering Manager, Senior Engineering Manager, Director of Enginering, Vice President of Engineering, Chief Technology Officer. While these names are useful in determining where a individual lies in the food chain, the names are merely hints as to what that person actually cares about… and you should care what they care about. Your boss and your bosses boss effectively sign your paycheck every two weeks and that means food. Sure, you can leave and go somewhere else, but there’s another manager there waiting for you with their own obscure agenda.

There are three distinct classes of managers, each with their own agenda. The common names for these classes are first line manager, middle manager, and executive/senior manager. Again, these names do a good job of giving you a clue where your manager sits on an organizational chart, but they don’t tell you what they actually do… how they are motivated… we need a different set of names for that. We need a set of names which don’t confuse us with an implied hierarchy.

INWARDS: These types of managers are generally responsible for a small team of folks working on a single product or technology. An Inward manager’s vision is focused on their team… what and how they are doing. While they’re aware there are other things going on in the organization, they don’t tend be involved with external shenanigans unless it directly affects their team.

HOLISTICS: Traditionally the middle layer of management. The vision of Holistics is across the organization. While they are likely managers of managers, their vision is across the company. They are constantly trying to figure out what the hell is going EVERYWHERE in the organization. This gives the impression that they are spread thin and/or constantly busy and they are, there’s a ton of information moving around in your average sized company.

What Holistics are looking for is strategic advantage. If they’ve done their job, they’ve hired rock star Inwards to get the products built to specification and on time so that they can focus on figuring out what to build next and how to get the resources to do so.

OUTWARDS: The senior manager. VPs, CEOs, and what not. The biggest misconception regarding Outwards is what they care about. You’d think their #1 priority would be the care and feeding of the company. Wrong. The well being of the company is, ultimately, the responsibility of the Holistics. They’re the ones who are spending all the time sniffing around the hallways, gathering internal competitive intelligence, and enacting new policies.

Outwards’ vision is focused on the outside world. They care about the public perception of the company, the company’s relationship with its customers, the financial community, the world. That’s why they’re never at headquarters, they’re off telling other people what a great job all those Holistics and Inwards are doing. This is not to suggest that Outwards don’t care about what’s going on inside the company on a day-to-day basis, it’s just not the their job to maintain it even though they are accountable for it. Tough gig.

Now that you’ve got a rough idea of the different management types, let’s talk about how it specifically affects you:

- While I’ve indicated how real world titles relate to these classes, they may not translate to your manager. You might be working for a manager who thinks he’s Holistic when he really should be Inward. This means they’re out combing the hallways looking for strategic advantage when they really should be paying attention to you, the senior engineer who has indicated, “There is no way in hell this product is going to ship on time”.

- Holistics are constantly searching for strategic advantage. There is a spectrum here with “advantage for the team” on one side and “advantage for the manager” on the other. Holistic managers who spend all the time looking for advantage for themselves are called “players”. These people are going to screw you at some point.

Similarly, Inwards who have been forced into the Holistic role are also going to screw you, but not because of any action on their part, but due to their inaction. They are Inwards, they don’t care about the political intrigue over in Building 27, they want to design and ship product, they want to dive into the details. Problem is, the political intrigue over in Building 27 will ultimately determine that your product is irrelevant. Now you’re out of a job because your manager’s manager didn’t attend that cross-functional meeting. Sorry about that.

- The idea of micromanagement is easier to understand with these classes. When you’re being micromanaged, it means two things. First, you are doing a bunch of work that you feel is unnecessary. Second, you feel the person asking you to do is being unreasonable. You’re right on both counts. Busy work is usually the result of poor planning by someone who ISN’T DOING THEIR JOB. Maybe it’s an Outward who gets panicky at the end of release cycle and starts acting like an Inward. Who knows? The point is, a manager is crossing from one responsibility threshold to another and that just confuses everyone. WHY AM I SENDING A STATUS REPORT TO CEO?

- The distinctiveness of these different management classes gets very blurry in smaller companies. The Holistics tenancies tend to be absorbed into both the Inwards and the Outwards. Translation: middle management vanishes in start-ups.

- Once an Inward manager has glimpsed/groked the responsibility (read: power) of the Holistics and the Outwards, they’re going to be motivated to head in that direction for some duration of time between right now and the rest of their lives. Recognizing that your manager is ON this quest is important because, well, they might not be there when you come in to work tomorrow. Plan accordingly.

Conversely, many seasoned Inward managers might be ex-Holistics and Outwards. This means they played game and decided to bail or maybe they were chewed up and spit out. Personally, I think these type of Inwards are phenomenal employees because they have a discernable agenda. Holistic managers and Inwards transitioning to Holistics have a lot more enthusiasm, but they’re hungry for your job. This is also a good thing, but it means you’ve got to run a lot faster.

Incrementalists & Completionists

I recently got into minor war of words with a co-worker regarding the proper solution to a problem with one of my products. As an aside, let me say that email is never ever ever never ever the right way to resolve controversy. Too much subtly is lost when you’re YELLING IN ALL CAPS. Don’t waste your time solving problems in email… stand up… walk down the hall… and look the person in the eye. You’ll live longer.

ANYHOW.

What was intriguing about my email repartee with the co-worker was that we weren’t disagreeing about whether or not we should do something about the problem. We’re arguing about how much we should do. The disagreement reminded me there are two distinct personalities when it comes to devising solutions to problems: Incrementalists and Completionists.

Incrementalists are realists. They have a pretty good idea of what is achievable given a problem to solve, a product to ship. They’re intimately aware of how many resources are available, where the political landscape is at any given moment, and they know who knows what. They tend to know all the secrets and they like to be recognized for that fact.

Completionists are dreamers. They have a very good idea of how to solve a given problem and that answer is SOLVE IT RIGHT. Their mantra is, “If you’re going to spend the time to solve a problem, solve it in a manner that you aren’t going to be solving it AGAIN in three months.” I used to think that architects were the only real Completionists in an organization, but I was wrong. Architects are the only RECOGNIZED Completionists in the company, but the personality is hiding all over the place.

Rewind to my email situation. The actual problem is irrelevant, but here’s the background. The co-worker discovered a problem in our product and reported it. I responded and suggested an minor improvement which didn’t solve the core problem, but was achievable given our schedule. The co-worker responded with “Why do this if we don’t solve the problem”. I responded, “We don’t have time to solve it and something is better than nothing.” Co-worker, “This is less than nothing!” Insert stunned silence.

Remember, the co-worker identified (correctly) the original problem. Why in the world don’t they see the value of my solution? The reason is, this is a Incrementalist doing battle with a Completionist. This isn’t the battle of wrong versus right, it’s the battle of right versus right. Bizarre.

How does anything get done with Incrementalists and Completionists arguing about degrees of rightness? Well, first, limber Incrementalists can switch teams. They’re opportunists and when they see that acting like a Completionist is a good move and, more importantly, it’s an achievable move, they’ll step up to the Completionist plate. Once they’re there, it’s likely they’ll engage a Completionist to do the heavy lifting, but the Incrementalist will drive because THEY CAN SEE THE PLAN FROM SOUP TO NUTS. This is a big deal for Incrementalists because they normally can’t see past their next meeting… getting them on-board with the “big picture” gives them a sense of foundation they don’t usually have.

Conversely, effective Completionists know when to let the Incrementalists poke around and do their thing. Completionists recognize where this Incrementalists with their rapid-fire buzz-speak fit into the corporate culture and they embrace their mania because they know it’ll help with their Completionist agenda. This, too, is a big deal because Completionists spend much of their lives shaking their heads, staring at the floor, muttering, “Boy, could they fuck this up more?”

A healthy population of both Incrementalists and Completionists is essential to a corporate agenda. It’s not only because they both represent groups that “get stuff done”, it’s also because they are going to argue, but it’s the argument you want your teams to have. It’s not “Should We or Shouldn’t We”, it’s “Let’s do this thing, let’s make sure it gets done, and let’s make sure it get’s done right.”

Managementese

One of my teams is facing a big fat decision regarding future product direction and the process has split the team in half the “Yes We Shoulds” and the “No Way in Hells”. The manager of the team is facing a minor rebellion and spending much of his time trying to drive the team towards the “right” decision.

A few days ago, I walked by his office and he was talking with one of the “No Way in Hells”, trying to influence them onto the other side of the fence. I overheard a blurb of his conversation, “I think it’s a key decision and I’m asking you to think outside of the box…”

I cringed.

Management speak.

Walking back to my office, I thought about my negative reaction to the term “outside of the box”. What does that actually mean? Well, it means something like “don’t restrict your thinking”, but when my boss says it to me, I hear, “I’M A MANAGER and YOU SHOULD THINK CREATIVELY.” No, that’s not right… what I hear is, “I’VE STOPPED THINKING and I AM USING THROW AWAY PHRASES THAT OBSCURE WHAT I MEAN”

Barfola.

As I sat in my office, a project manager came in for a 1:1. With the observation fresh in mind, I attempted to monitor all my usage of managementese during our half hour meeting. Here are my offenses:

“Can you CIRCLE BACK with her…”

“I want to DOUBLE CLICK on that and…”

“These are the ACTION ITEMS…”

What I learned: I’ve turned into a total dorkwad manager and can no longer communicate like a normal human being.

One of my favorite books on software construction is Steve McConnell’s _Code Complete_. In the second chapter, McConnell describes the richness of language around computer science:

“Computer Science has some of the most colorful language of any field. In what other field can you walk into a sterile room, carefully controlled at 68 degrees fahrenheit and find viruses, Trojan horses, worms, bugs, bombs, crashes, flames, twisted sex changers, and fatal errors.”

He continues:

“A software metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer, it tells you how to look for it.”

With this advice in hand, I’d always assumed that management metaphors fell into the same bucket. They don’t.

Managementese is the language which is learned, evolved, and spoken by managers. For communication between managers, it’s a convienent, high bandwidth means of conveying information. Chances are, when you say “double click” to a fellow manager, they understand you are suggesting that they should carefully check the work/task/whatever.

When you say “double click” to an employee, they know what you’re talking about, but they also know that you’ve just self-identified as a manager by flaunting some mumbo-jumbo in front of them. Why didn’t you just say what you actually meant? Are you sure they actually understood what you meant? Management metaphors obscure meaning and confuse those who aren’t lucky enough to be managers.

There are unique spheres of language which exist at each part of the corporate organization chart. Inside of the sphere is the language which is unique to the job. Engineers have one, marketing has another, and sales has yet another. In each of these groups, there are the managers who must speak their native language as well as be able to translate between spheres in order to get the job done.

Managers are hubs of communication, the better they communicate across these sphere boundaries, the more people they can communicate with, the more data they have, which, consequently leads to better decision making. Ultimately, stronger communicators make more informed decisions and, hopefully, are more successful because they waste less time wondering what to do.

Out of context use of language leads to one thing — confusion. Rather than conveying the information they wanted and getting to the task at hand, a manager who bumbles their communication is going to end up doing it again a week later. Even worse, maybe the painfully confused team isn’t going to say anything about their total lack of direction and the manager is going to be in real damage control mode weeks later.

In high tech, we’re all in incredible fucking hurry. We’re working against an unreasonable deadline, we’re over committed on features, and, now that times are tight, no one is paying for pizza on weekends. As a manager, you’re job is that of a bullshit umbrella. You need to decide what crap your team needs to deal with and what crap can be ignored. That means you need to rapidly acquire information from a variety of people… In that rush, managementese can help you talk with your fellow managers to figure out what the hell is going on, but you’re only half done. You still need to communicate to your team.

This can be tiresome because you, of all people, are absolutely sure what you’re saying. This is why you might be tempted to use the readily accessible management metaphor laced language which you’re familiar with. Don’t. Think back to when you were the junior grade programmer and that first layoff came around… and you were wondering, what’s a layoff? Am I being fired? If so, when? And why?

95% of the people in a big company simply have no clue what corporate machinations are going down and how they might affect whether or not they’ll be working in the next six months. How you will be judged as a manager by your team is based on how you communicate with them. That’s not just taking the time to have that QUARTERLY ALL-HANDS, it’s understanding what they need to hear and being able to say it in a way they’ll understand.

To-Do Lists

Somewhere between individual contributor and middle management, it became essential that I have a to-do list. I resisted this for years, secretly hoping that I could keep track of all the crap I needed to do in my head or an a convienently located post-it note, but then stuff started spilling all over the floor and I started getting yelled at.

Enter the to-do list.

After trying out many different tools and processes for tracking to-dos, I’ve reluctantly settled on using an Excel spreadsheet. Each to-do contains the following information:

WHAT:
The to-do

PRIORITY:
0 - Now (must do today), 1 - High (this week), 2 - Medium (Whatever)

TEAM:
Which team is the to-do related to

STATE:
I’ve recently added this to the spreadsheet because I needed finer grained control that Priority gave me. Currently, I have three states: NEEDS ACTION which means “move on this”, TARGETTED which means “action has been taken, next step is NOT mine”, and BLANK which means “Uuuuuh, need to triage this”.

NEXT STEP:
If the to-do has been triaged, what’s the next thing that needs to be done? This also gets used a lot for random notes.

SUBMIT DATE:
When the to-do was submitted. I used to highlighted issues based on how many days had passed by submission, but other than adding a lot of color to the spreadsheet, I mostly ignored it.

EXECUTIVE:
This is a boolean. True means executives care about the issue, False means the opposite. This is basically an acknowledgement that Executives, by definition, care about seriously random stuff and it’s more important to aggressively follow-up on the issue rather than debate why they care about it. Separating this means I can leave priority as a representation of my opinion rather than being artificially inflated by an Executive fire drill.

At the time of this writing, I’ve currently got 73 active to-do items on my spreadsheet… 21 which I’m supposed to handle today. That’s about the norm.

I’m content with my to-do set-up because Excel is flexible tool and as I my process changes, so can it. I heavily use the filtering and sorting features to slice and dice my to-do list throughout the day to make it appropriate for the team/people I’m dealing with, but I’m wondering out loud what other people use to track their to-dos. Surely, someone brighter than me has come up with a more robust solution/tool.

Definition of a Bad Bug

My favorite part of shipping a product is crunch time. It’s the month or so before a major release when you’ve acknowledged that you can no longer delay the inevitable — you must ship this product.

What’s gratifying about crunch time is the velocity with which the product team moves. Decision-making occurs in the hallway. Meetings which used to be an hour shrink to twelve minutes so folks can get “get back to doing real work”. White boards are written on… food is delivered at @ 10pm. Families are ignored.

Invariably one of the biggest decisions that must be is, “whether or not we can ship with this bug”. Hundreds of hours will be spent on bug triage and a ton of time will be wasted by folks defending their favorite bug. To help simplify this, I offer the criteria I use for defining a “bad bug”. A tip of the hat goes to Pac-man who originally mentored this into me.

1. Is it heinous?

First, you must acknowledge that there are bugs when you ship. That is a fact. Can this bug be one of them? Would we spin a quick re-release if this bug were discovered a week after ship? If YES is the answer to all of these questions, you move to…

2. Do we understand the bug?

Why is this bug occurring? What changed in the product to introduce it? If you get past #2, YOU’RE NOT EVEN HALF DONE YET… Deciding to fix a bug and actually producing a fix are two drastically different events. Everything is supposition until the engineer comes back with a fix in hand. This leads us to…

3. Do we understand the fix?

For #3, you’re really after secondary and tertiary effects. Ask yourself, do you really understand all the ramifications of the fix? Really really? Really like my next four raises are dependent on it?

The types of questions you ask for #1 through #3 will vary depending on the type of project you’re developing, but of the main questions, however you define them, should be asked for each bug late in the game because any change to the product is risky.

I love when an engineer says, “It’s just a string change!”. Sure, that’s a pretty low risk change, but getting the product out the door is a hell of a lot more than just making sure it compiles on engineering machine. Did the change get correctly submitted to CVS? Are we sure this is the only change submitted? Does the new version build for the build engineer? Wait, is it localized? I could go on and on with examples of places that folks can fuck up the product with a simple string change.

The goal for any product whether it’s an operating system or a consumer application is to get to a steady state where folks stop messing with the bits. It’s only then that your qualification organization can test against a know quantity and every single change to the product increases the risk that you’re no where near ready to ship.

FYI, for comparative purposes, the catholic catechistic criteria for a Mortal Sin is:

1. Grievous offense
2. Sufficient reflection
3. Full consent of the will

Reorgs for the Average Joe

You’ve been here…

You get a random email from your boss that you need to meet with him urgently at some odd hour of the day. You sit staring at the email, wondering what could be up. No rumors of layoffs are in the air… the company is hitting it’s number this quarter. You don’t believe you’ve done anything to merit a “talking to” outside of your regularly scheduled one-on-one, so… what’s the deal?

The time comes for the meeting and you decide to not bring your laptop or your notebook. When you walk in your boss’s office, you look into his eyes and immediately know…

You’re about to be reorganized.

My boss was fairly good about it. He came right out and said that part of my group was moving. He explained the justification and asked me for my thoughts. We chatted a bit more and then he blew it, “I held off from telling you because things are changing so much and I didn’t want to jerk you around. Things have now settled down.”

Hah. Right.

Before we rip on the boss, I’ll explain what exactly a reorg is and offer some advice for the Average Joe on how to weather the chaos. First, a reorg is not a layoff. Layoffs can occur as part of a reorg, but they are a side effect, not a cause. Tips and tricks for dealing with a layoff is an entire other article. Reorgs are when teams and products are shifted around in order to account for some external change. What kind of change? Who knows. Maybe the market has shifted or maybe the economy is crap. The point is, someone, somewhere in the executive chain decided, “We need to make an adjustment in the organizational structure”.

Below are some useful rules to pay attention to during the reorganizational chaos as well as some tips and tricks for surviving them.

RULE #1: News travels at different speeds & people are paranoid

As mentioned above, reorgs start to serve a single purpose and then the political intrigue kicks in. From the moment an executive says “reorganization” until days after the reorg has actually occurred, the company rumor mill kicks into high gear. Who is going where and why? Are there layoffs? Why is it happening and when?

There are truthful answers to all of these questions and then there are rumors. Particular hot tidbits of can travel through the organization like wildfire even when a reorg is being kept on the down low because people are paranoid and want to know what is going on. These tidbits will confuse you not only because you won’t be able to discern the fact from the fiction, but also, the information will travel at different speeds depending on their journey through the organization.

Here’s the scenario. When your boss finally breaks down and tells you, “It’s settled. Your organization will not be touched. Don’t sweat it”, you’re going to be relieved. Problem is that it’s also likely that someone, somewhere discussed potential, unrealized changes in your organization and when that fact find it’s way to your desk several days later via tip from a close friend, you’ll be wondering, “What isn’t the boss telling me?” Guess what, now you’re paranoid.

This sea of fact and fiction swirling around at different speeds is the biggest problem with reorganizations. A bungled communication plan means, for the large company, days and days of lost productivity because Average Joes are suddenly not worrying about shipping product, they’re wondering if they should be looking for a job.

Average Joe Advice: Fact of the matter is, your boss is probably fairly well informed and he/she is speaking the truth as best he/she can. Every other piece of data that ends up on your plate should be suspect even if it’s from a credible friend. They might be trying to be helpful by telling you, but who knows where they got their data? (See Rule #2: “The Grapevine”)

RULE #2: “The Grapevine” or People hear news in terms of what they want or People are really, really paranoid

A major contributor to the rumor chaos around reorgs is the grapevine. Simply put, information that starts out as fact slowly becomes more and more rumor with each transition from one person to another. Let’s watch:

VP of Engineering to Her Staff: “They’re building a new hardware group under Ted. It’s not clear where they’ll be getting the headcount. One option would be to sacrifice headcount in other groups.” (What happen: VP stated the facts where she could, trying to give her staff a heads up)

Manager of Engineer to His Staff: “Ted has a new group. We’re liable to lose a headcount in our group.” (What happen: He starts with the facts and then follows up with a strong opinion, he’s losing a headcount. Why is he saying this? Maybe he’s been with the company for years and knows that when his boss hints at something, it’s going to happen.. who knows. The rumor mill is now officially in effect.)

Sr. Engineer to His Friend: “We’re losing headcount and it’s going to Ted’s new group. Gosh, I hate Ted.” (What happen: What was fact is now full fledged rumor ready for rapid consumption into the grapevine. YAY!)

This is simple example, but it illustrates basic human nature. We want to know what’s hell is going on and when we don’t, we’re likely to make stuff up which gives the impression we do.

Average Joe Advice: Once the rumors start flowing in your particular reorg, some pretty radical stuff is going to cross your desk. I guarantee you that while much of the tidbits are crap, there are likely gems of truth in each piece of information. I advise a journalistic policy here where you confirm tidbits of information with independent sources before you start pulling your hair out.

RULE #3: Reorgs are never going to feel like they’re over (and they’re not)

The time from when you hear about a reorg to when it’s actually executed is going to be four times as long as you think. Reorgs take forever. Plans are designed, confirmed with stakeholders, adjusted with feedback, run up the flagpole with the Big Boss, and then taken back to the drawing board. All the while this “official” process is going on, there are hallway shenanigans going on as individual political players are jockeying for headcount. All of this information is informally inserted to this process, forcing even more iteration.

Average Joe Advice: My advice here is pretty simple. Reorgs take a long time and create a lot of noise. You can either choose to become a fanboy of the reorg and pay attention to every little detail or you can do what you were hired to do, work. If you choose the fanboy route, I suggest a regimen of active listening and aggressive hallway conversation acquisition.

If you’d prefer to ignore the reorg, I recommending sitting backing in your chair and enjoying the scurrying about. Take comfort in the fact that you’re still employed and, hey, if the reorg affects you, maybe a change of scenery is going to do you some good. Don’t forget to ask for a window in your new office.

Incidentally, this is where my boss blew it. By telling me, “I didn’t want to jerk you around” and “it’s all settled”, I realized he was reasonably new to the whole reorg process. In the case of my company, the reorg had just begun a few days before and I knew, given the size of the company, we were due for, at least, two to three more weeks of organization churn. (Note: I started this article the day the boss delivered the news, it’s been two weeks since then and the buzz has not yet stopped).

RULE #3.1: Most folks actually love reorgs (but hate to admin it)

This is tightly related to Rule #4. Reorganizations represent opportunity to those who are unhappy with the state of the current organization. As mentioned above, the moment organization stakeholders hear there is a reorg brewing, they start working the grapevine to steer the course of the reorg in their favor. When you combine this fact with people’s love of gossip, you’re guaranteed a big juicy, drawn-out reorganization.

While you, the Average Joe, may be annoyed by all the hallway conversations and closed door meetings, the fact is, most folks love this shit. Who is getting moved? Really? Wow. No way? He’s an idiot! That blows! Etc. etc. For some reason, conversations about reorgs sound a lot like conversations about infidelity.

The group responsible for generating the most noise around reorgs, ironically, is the group who has the least affect on their eventual outcome, the Average Joes. These are the people who are lingering in the dark while the management team wades through strategy, political agenda, and fiscal responsibility looking for a plan which gets the company out of wondering who works for who and starts worrying about building product again.

Delivering Big/Bad News

As a manager, at some point, you’re going to have to delivery news that is going to be of significant consequence to your employees. It’s likely to either be big news (“the team has been split into three and everyone you know is no longer on your team”) or it’s going to be bad (“we need to put you on a performance plan”).

There is probably a lot to say about how to do this well, but I want to focus on the single biggest mistake I’ve made when doing this… not giving the person time to think.

Traditionally, big/bad news is something you sit on for some time either because you have to (i.e. the timed execution of layoffs) or because you’re not looking forward to saying whatever it is you need to say (i.e. performance plans). Regardless, you’re probably going to have the big/bad news percolating through your brain for many days before you deliver it. You get comfortable with the news in that time, it becomes second nature, and less big/bad.

Fast forward to the time when you need to deliver the news to the team. In your one on one, you carefully explain the ins and outs of the situation, you summarize, and you’re done. Whew. That was easy… I thought that was going to be hard. Next topic!

Here’s what happened in the head of your employee on the other end of the table…

“Boy, the Boss is about to say something big, he/she is really nervous.”

“Ok, Boss, cut the chase, how is this going to affect me?”

“… I’m laid off? Wuh?”

Fact is, you kept on talking after you delivered the punch line (laid off, reorged, whatever), but your employee stopped listening at the punch line. They did not hear all your fabulous rationalization about the big/bad news that came after the punch line because they’re basically not sitting in your office, they’re wandering around the inside of the head trying to do all the metal digestion that you did in a week in mere ten minutes… with you yammering away about trivial details.

When it comes to the end of the big talk, you’re going to feel pretty good because when you ask, “Any questions?” you get a blank stare and no response. You will confuse silence for understanding because you didn’t want to deliver the big/bad news in the first place and just want to move on.

Problem is, come the next day, the employees are going to have had actual time to think and they’re going to be stacked three deep outside of your office with comebacks to your punch line that you never thought of.

The fix here is simple. Give them the time to think. When delivering momentous news, tell them that you’re not expecting them to react right now and you prefer if they took the day to digest and come back to have a real conversation the next day.

When you can give your team time to think about the big/bad news, you take the pressure off them when you deliver the punch line. My usual mode of operation is to preface that I’m about to deliver the news, explain I’ll answer any questions they have, but that I’ve already scheduled time on the following day to have the real conversation. I, then, deliver the punch line.

Sometimes there are immediate questions; sometimes there is painful silence. Regardless, come the next working day, they’re full of opinion.

This advice works for most big/bad news except for layoffs when someone is delivered the one-two punch of “you’re laid off” plus “get the hell out”. I’m convinced this intensely blunt way of dealing with people in layoffs is one the reasons employees get pissed and do destructive things during layoffs… they have no means of digest the news in a constructive way. They’re just gone without time to understand what actually happened.

Synchronicity

I build software for a living. I started out in quality assurance in the 80s and now I’m responsible for a reasonably large engineering organization tasked with developing four very different products. This week, the team sat down with the executives at the company and basically asked for several million dollars to finance the development of out product.

They said yes.

I’m assuming the process is similar at various large-ish companies. The engineering and marketing teams put together the goals for the next release, they throw together some designs and some pretty slides, and then take the dog and pony show to the execs who nod a lot, ask a few questions, but ultimately trust the team to do what is best.

Sounds easy, right? Want to know the hardest part? It’s not finding good workers, thinking up innovative ideas, or even the laborious bureaucracy? it’s simple communication.

Before I explain, let me first confess that my prior gig was a start-up. Getting product approval involved getting the CEO, the CFO, the VP of Marketing, and myself in the same room for half-a-day and, viola, we had a one year product roadmap. I am used to having complete access to the decision makers, so big company development processes is terra incognito for me. The good news is that I’m pretty much done with a full design cycle and they only big surprise was how much confusion (and subsequent extra work) was caused by a single poorly defined word.

The product in question is mostly irrelevant, but one thing that is does involves file synchronization. For those of you who aren’t computer science majors, file synchronization is really, really hard. The basic idea is trivial: I’ve got one version of a file on my portable or PDA and another version on a server/desktop. File synch tools attempt to compare the two file, determine which is newer, and copy the newest version to the right place. (I.e. if the server is new, we copy to the portable device and vice versa).

Simple, right? Just compare file modification dates and you’re ready to go. What if BOTH files have been modified in BOTH locations? By different people? Yuck. File synchronization goes from being a mouthful to being darned near impossible depending on what you ask of it. It doesn’t help that it turns out that most people don’t have a clue what it means.

In order to get my product built, I had to present to five different groups of people. There was my immediate team of engineers, my product managers, my marketing folks, my senior management, and the executive management. My presentation had a good statement of direction, some slick architectural slides, and an aggressive schedule. I included a bunch of statements by customers who claimed our product would solve all their problems? I thought I was very well prepared.

The problem was I did not define synchronization in terms of the product I am planning on building and not a single person asked. This meant that everyone who walked out my presentation had their own personal definition of what synchronization meant. Some thought it was just backing up files, others thought it was the basic single user case I described above, while others thought it was the sophisticated multi-user case. No one, except me, really knew how we were tackling synchronization.

Here’s what happened. People from the engineering meeting met with people from the marketing meeting and the marketing folks said, “Hey, did you hear about the cool product Rands team is building? It does multi-user full file synchronization!” The engineer types — who had the best idea of what we were planning — would look at the marketing types like they were crazy, “No he’s not, he’s doing the simple case because the multi-user case is damned near impossible.” “WHAT?! That’s not what he said in his presentation! We can’t market simple synchronization!”

And so on…

By the time I got to the executive review, the hub-bub about the synchronization vagaries had bubbled up to various VPs along with the usual grapevine signal to noise degradation. The rumor that my head was deeply implanted in my ass regarding this particular product was firmly entrenched in various powerful brains which meant I got asked some fairly tough questions mostly in the realm of, can you guess, synchronization.

Fortunately, I actually knew what we were doing with regarding to synchronization and that we would be developing a compelling product with that strategy. When it became clear to everyone else that I had a clue, they recommended that I circle back with the various product fiefdoms to “make sure everyone is goal aligned”. What should have been five meetings turned into ten and that doesn’t include the time reworking multiple presentations and specifications to carefully describe our synchronization strategy.

It’s easy to blame the word synchronization in this story because it’s so ripe for misinterpretation, but that is not really the point. Big companies are big because THEY HAVE LOTS AND LOTS OF PEOPLE. In my prior start-up life, the synchronization confusion would have never had a chance to grow out of control because I saw everyone responsible for getting product out the door every single day. Hallway conversation does wonders to contain viral rumors.

I’d like to give some good advice here to others facing large company communication problems, but so much depends on what you’re trying to trying build, who you need to ask permission of, and what’s the relative aptitude of those influencers and decision makers.

Perhaps the best advice is to carefully look for those blank stares when you’re presenting especially if it’s on the face of your VP of Engineering. Blank stares indicate confusion and confusion means more meetings.

Engineering Management Interview Questions

A former employee recently asked, “What are questions you ask software engineering management candidates?”

These questions really focus on the people-skills for managers. If you’re looking for technical questions, I highly recommend techInterview or Topcoder.com.

Lead Off Questions:

These are vanilla, boring questions which I use to begin to assess a candidate. I usually base follow-up questions on the answers to these questions. One word or short answers to any of these questions, in my opinion, are significant red flags.

- How do you lead?
- How do you communicate information to your team?
- How many people have you Hired/Fire/Laid Off/Promoted? How do you go about it?
- Have you had a position with budgeting responsibilities? What was the size of your operating budget?

Follow-up Advanced:

Here we start to get into some meat. We�re looking for meaty answers here:

- Compare your role (as an engineering manager) to that of the individual contributor
- Compare your role (as an engineering manager) to that of your manager (sr. manager, director, vp of engineering)
- Other than your direct reports, who in your organization do you depend upon most to get your job done?
- Describe your best hire. Why were they your best hire?
- Describe your worst hire. How did you manage him/her?
- How do you prepare for your staff meeting?
- Do you have a to do list? How do you manage it?

Follow-up Even More Advanced:

The serious meat. Tough questions which reveal much about the management style of individuals.

- Have you developed a product without a marketing requirements document? If so, how?
- Have you developed a consumer product without a user interface specification? If so, how?
- How have you improved as a manger over the years?
- Describe a situation where you had to deliver really bad news to a team/person. How do you approach the team/people?
- Describe a situation where you were suggesting a course of action which you did not necessarily support
- What event made you least proud to be a leader?
- Describe a situation where you were given conflicting priorities. How did you resolve that situation?
- What was your most recent big mistake? Why did it occur and how do you repair the situation?

IF YOU SEE A SNAKE...

Jim Barksdale of Netscape fame offers us these management nuggets:

If you see a snake, kill it.
Don’t play with dead snakes.
Don’t forget that great opporunities look like snakes at first.

SURREAL MEETINGS

At the new gig, everyone is sporting fancy laptops and the whole building is wired for 802.11b. This has some significant implications on the way work gets done in a meeting.

First, let’s describe the average well-run product development meeting in a non-wireless setting.

A bunch of folks show up. The alpha person has provided an agenda beforehand and each person has read that agenda and determined what they need to know/bring to the meeting. It’s likely if they needed to bring something, they printed it out or forwarded to the rest of the team so they could print it out.

The meeting begins. The agenda is followed. Brainstorming occurs and action items are assigned for questions which are asked, but can not be easily or honestly answered. Print-outs are examined; more action items are assigned because of additional unanswerable questions. The meeting completes, actions items are pondered, print-outs are thrown away, and the cycle repeats itself.

Now, add wireless and let’s see what happens.

An agenda is sent out, but the amount of preparation which occurs less because you know, going into that meeting, you’re bringing your entire desktop to the meeting in the form of your wireless notebook. What else do you need? Why print out what you have?

The meeting begins. The agenda is followed. Brainstorming occurs, but there is decrease of action items because you are able to dynamically problem solve. Wondering about the status of that bug? Well, fire up your bug system and take a real time look. Forget to forward your slide set to the team? Mail it now. Save a tree. The meeting finishes and there is a distinct lack of action items because most questions were answered. Folks leave the meeting and silent ask themselves, “Why do we have that meeting?”

Now, I’ve described a semi-fairy-tale-like scenario above and the reality is a bit bleaker. Wireless-equipped meetings do feel more productive because of the presence of much data, but that data can be a distraction because not only do have access to bug databases, project schedules, but also PORN AND INSTANT MESSAGING WOOOOOOOOOOOOO.

These distractions lead to a lot of people typing away during meetings and the impression that they aren’t actually paying much attention. Sure, they might be digging up a specification because they know it’s required reading come the next agenda topic, but they also might be checking their stock portfolio. Who knows.

My impression is that wireless access etiquette will evolve at a company. There will be meetings were access will be required (where timely access information is essential) and meetings where it will be forbidden (where focused, creative thinking is valued).

Whether it’s a cell phone in your car or a wireless notebook in a meeting, the argument is not whether it’s a good thing, it’s a question of how much of your brain you want to do the devote at the task at hand.

ACRONYMS, ABBREVIATIONS, AND BUZZ

I’ve been browsing Dive Into Mark’s “30 Days to a More Accessible Weblog” and came across a great intellectual exercise.

His Day #17 entry “Defining Acronyms” listed 51 acronyms and abbreviations that he’d recently used. They were:

ADA, ALT, AOL, API, CGI, CMS, CSS, CTRL, DMV, DNS, DTD, EFF, FAQ, FSF, GFDL, GIA, GPL, HTML, IE, IIRC, IIS, IO, KB, KDE, LONGDESC, MB, MSDN, MSN, MT, Mac, NC, OPML, P2P, PGDN, PGUP, PBS, PDF, PONUR, RSS, RU, SOAP, SSN, TDD, US, VNC, W3C, WCAG, WYSIWYG, Win, XHTML, XML.

(Yes, I know he says there are 50… there are 51… I can count… Mark can’t.)

The exercise was this: Given this rather tech-centric list, how do they various acronym look-up sites do? I picked three sites: Google, Acronym Finder, and Acronym Search. I made up the rule that I would give the site a point for a correct definition if the acronym showed up on the first result page.

Acronym Finder: 90%
Google Glossary: 71%
Acronym Search: 73%

Random observations:

- This is not really an apple to apple comparison. I’m assuming that Google is building the glossary list based on their crawls of the web whereas the other two sites specialize in this sort of thing and accept submissions to improve their data set. This is a back handed compliment to Google since without really specializing in acronyms, they fared pretty good against a specialized site.

- Nobody knew what GFDL stood for - according to Mark it stands for GNU Free Documentation License. Strangely enough, the Google front page point straight to the thing which is odd. Knowing nothing about how Google creates it’s glossary, I would’ve assumed they would’ve mined popular search results for acronyms.

- Nobody knew what IO stood for, either… including myself. A regular Google search didn’t find Mark’s definition either “Instant Outlining”. This observation makes a valuable point regarding acronyms. They usually start at as time saver for some collection of people who ARE REALLY TIRED OF TYPING INTERNATIONALIZATION AND WOULD PREFER TO TYPE I18N. Problem is, the context which makes the word meaningful doesn’t travel around with the world with it, so you end up needing glossaries or acronym finders. I still don’t know what Instant Outlining is, but it’s probably important to Mark and his clan. (Note: this probably applies to other unknowables such as PONUR)

- Here’s the list of words Acronym Finder knew that Google did not: ADA, CMS, OPML, PGDN, PGUP, RU, VNC, WCAG (wow), and Win (probably too common of word). Yes, some of these words are abbreviations and not acronym. SAME DIFFERENCE IN MY BOOK.

- Acronym Search didn’t know what XHTML stood for. That’s our dumbshit award for the contest.

Why all this energy regarding acronyms, Rands? Well, it’s not really acronyms that I’m concerned about, it’s glossaries. Being in high tech, I’m inundated with a steady stream of acronyms, abbreviations and buzzwords. We geeks love to create them because we essentially like to build stuff and IT AIN’T REAL STUFF UNTIL IT’S GOT A GOOD ACRONYM OR CODE NAME.

Unfortunately, these words confuse people. They lack context until they reach critical mass and that means corporations are ultimately losing money because they’re people aren’t able to talk to each other. PLEASE GET THE P39 QA’ED ASAP BEFORE ROGER LANDS HIS XHTML BRANCH OR WE’LL ALL BE SOL.

I’m sure many companies already do this, but I’d recommend that any largish project should have an accompanying glossary of terms. This is living document which draws the lines between the buzzwords and the content. Yes, it will take extra time to generate this document and, yes, it will always be out-of-date, but some data is better than none.

(ps. oh yeah, Mark’s idea to use the acronym tag is a good one. Do it.)

Your Resignation/Layoff Checklist

I’m switching jobs over the course of the next week. Been with the current gig for about four years and the stench of idiocy was getting terribly strong, so… Splitsville.

A STATE OF THE JOB MARKET ASIDE: I realize it’s a tough economy right now, but I really had no problem finding a new job in the Silicon Valley.

During the course of one month, I got enough traction for a variety of different gigs to say that, for technical management, there is no reason you shouldn’t be able to find a job if you keep the scope of what you want to do broad enough. I’M REALLY SORRY IF YOU’VE BEEN UNEMPLOYED A LONG TIME AND WANT TO YELL AT SOMEONE.

Here are the beginnings of a checklist of things you want to do your last week on the job.

DON’T PROMISE WHAT YOU CAN’T DO: If you’re resigning, you’ll be tempted to over commit on deliverables before you leave. This is guilt talking. You feel bad for resigning and are trying to make up for the fact that you might people leaving in the lurch. Remember that no matter how hard you try, you will become useless in your final days.

PRACTICAL EXPERIENCE: I totally blew this in past resignations. YES I’LL REWRITE THE IMPORT/EXPORT ENGINE IN TWO WEEKS NO PROBLEM ANYTHING ELSE? I purposely skimped on the deliverables and also completed whatever I committed to with a week to spare because, face it, my engagement level in that last week was minimal.

RESPECT YOUR NETWORK: There are, at least, three people you’ll need to make sure are aware you want to stay in touch with them. I don’t know who these people are because I don’t know who you are or what you do. If you’re looking for a way to identify these people, pick the people that you respect or maybe pick the people you hang out with outside of work. Or both.

No matter where you are in your career, you need to continually develop your network of people because it’s very likely that one of those three people will assist in future employment/opportunity. Personally, I’ve been in high tech for over ten years and every single job I’ve got has either a direct or indirect result of knowing someone from a prior job. You’ll hear the phrase, it’s a small valley. It is.

PRACTICAL EXPERIENCE: This was easy. Every manager reporting to me, the CEO, and the Director of User Interface. Helped that these were all drinking buddies.

DON’T TAKE CHEAP SHOTS: If you aren’t leaving under the best of terms, you’ll be tempted to send out the scathing email which “sets things right”. This is stupid on many levels. It will negate any positive work you did while you were with the company. Also, you’ll hurt your network because everyone (including those who know that you aren’t insane) will remember you as that freak that yelled in email and didn’t bother to spell check.

Remember, you are leaving and the people you consider to be the problem are staying. It’s not your problem anymore, don’t waste your energy.

PRACTICAL EXPERIENCE: We had a B- QA engineer at the company who got passed over for a promotion and decided to bail in style. On the last day of his employment, he sent a grammatically painful email which went through his organization, person by person, and hammered them. His incoherent rambling is still posted on some cube walls for its comedic value and no one has a clue that he actually wrote decent test plans.

DO RIGHT BY THOSE WHO WORK FOR YOU & WITH YOU: If you happen to be in a management position, the previous two comments apply to you in triplicate. You’re not allowed to fall prey to the dreaded “short timers’ disease” because you are acting like a leader and representing the company until the second you are out the door. If this doesn’t make sense to you then it’s likely you weren’t supposed to be a manager in the first place.

PRACTICAL EXPERIENCE: I’d give myself a solid B in this category. I’ve definitely succumbed to short timers’ disease in the form of daily 4pm exits, but I also decided to give written reviews to all my direct reports in my last two weeks. WELL WRITTEN REVIEWS ARE PAINFUL AND TIME CONSUMING. I was surprised when I handed the final reviews off to our HR and my HR rep said that no other manager had taken the time to do so. HELL YES.

Getting out the door at any job is always a tough proposition. You either want to go and rapidly realize that everything you do in the old job is useless or you’re laid off and you want to punch someone repeatedly. In either case, it’s important to remember that you’re not the only person going to through significant change. The people you’re leaving behind will likely be similarly dazed. Going out in a profane blaze of glory will leave an indelible impression on their confused minds. Is that how you want them to remember you?

THE BIG QA FREAK OUT

Mondays in the software biz are hell. Because productivity decreases in relation to how you close you are to Friday, Mondays, invariably, are full of everyone’s guilt to actually catch up on all the crap they ignored during the end of the week.

This Monday’s freak out was courtesy of my QA (“Quality Assurance”) lead. I heard her simmering in the hallways all morning. She was talking in hushed tones to a variety of people, building up her freak out just for me. I quickly escaped to an offsite lunch, but was immediately leapt upon when I walked into the office…

“Rands, can we talk for a minute?”

Shit.

We walked into the closest conference room; I gripped the table and braced myself.

“DEAR LORD WE’RE GOING TO SHIP HORRIBLE PRODUCT AND YOU’RE SETTING UNREALISTIC DEADLINES AND QA ALWAYS GETS THE SHAFT AND DO WE SUPPORT INTERNET EXPLORER 4.0 AND MY CREDIBILITY IS ON THE LINE HERE AND JESUS CHRIST DIDN’T WE LEARN OUR LESSON LAST TIME CHRIST GOD I HATE HTML AND THIS DEVELOPER KEEPS ON DIDDLING WITH SHIT.”

Rands Rules o’ Software Management #1: If someone is going to freak out, it’s going to be on a Monday.

When you witness a freak out, it’s important to quickly assess whether or not it’s a Monday or not. You also need to follow a couple of easy rules:

Don’t participate in the freak out.

This can be difficult because, hey, it is Monday and you did take last Friday off to play disc golf and smoke dope, oh my god, this person freaking out in my cube is ABSOLUTELY RIGHT AND LET’S GO TO THE CEO AND MAKE THIS RIGHT. Trust me, the CEO is much more adept at identifying freak outs than you and if you show up on his/her desktop blithering and throwing dry erase markers, you’re losing valuable respect points by the moment.

A less obvious participation maneuver is to make an important decision based on data acquired from a freak out. Remember, this data has been tainted by Monday and if you don’t wait to Wednesday to see what actually is going on, you’re an accessory to the crime.

Learn to recognize common freak outs.

Every person in the organization has their button which, when pushed, will result in a freak out. It varies in content and volume, but they always exist. Your job as a manager of people is to quickly discern where these buttons are and predict freak outs before they occur.

As was my case, I’d been expecting my QA freak out for over a week. Every software project I’ve worked on has had one as soon as someone with authority starts getting tense about dates. WAIT YOU MEAN WE HAVE TO ACTUALLY DO WHAT WE SAID WE’RE GOING TO DO? FUCK THAT.

Give the freak the benefit of the doubt.

Chances are your freak really does have something to say, they’re just under the influence of Monday. They probably drink too much coffee, as well. It’s important to try to determine what the person has to say although it might be easier to discern come Wednesday. Even if you can’t sift through the noise, the act of doing so might calm the freak a bit.

Hammer the freaks with questions, present them with facts.

Ultimately, a freak out is about the desire to be heard. Properly timed and correctly constructed questions will lead your freak down a road where he/she may find their own answer. If questions aren’t working and you’ve predicted this freak out then hammer the freak with readily accessible facts.

As with the case with my QA freak out, I had a good two hours in the morning to sniff the prevailing winds which meant I leapt into our bug tracking system to figure out how many bugs this person had filed, what were their severity, as well as other juicy tidbits.

When the freak out began, I started asking leading questions, “How do you know this?” “What facts do you have to support this opinion?” When it became apparent that the QA person was working from an emotional state rather than a logical one, they began to calm down. Thus begins the cooling period.

Get the freaks to solve their own problem.

If you’re lucky and your freak has half-a-brain, they probably already have a solution to the problem in mind. This is good news for you because it means all you have to do is listen to yelling for a good fifteen minutes while the freak wears out. After that, a few well designed questions will reveal a suitable answer and you’ll look like a hero for sitting there and nodding.

WARNING: The worst type of freak out is one which is purely emotional, non-logical, and based on little to no fact. It also lacks any type of solution because there really isn’t any problem except that this person really needs to freak out. The volume in this type of freak out can be negatively intoxicating and you’ll be tempted to jump on the freak out band wagon. Don’t. The best move here is to simply listen and maintain eye contact. Your calmness is a primal attempt to telepathically reflect the insanity back to the freak so they will realize they’ve gone off the deep end.

In ten years of software development, I’ve discovered that most freak outs are a symptom of a larger communication problem in the organization. The information your freak needs readily exists somewhere, but, for some reason, they lack the network of resources to find it. Fortunately for them, they have you, the manager who got to where you are because of your superior network of resources and information. The question, why did they have to freak out to get access to it?

No Title

Last night a colleague mentioned there are two ways to motivate a team:

• Unreasonable deadlines
• A mortal enemy

This is true. These are definitely ways to get the troops in line. In fact, after two glasses of red wine, I was staring at these two options thinking, "This might solve my hard problem." My hard problem is that Fridays have died at THE COMPANY. I’ll explain.

First, the CEO telecommutes from Chicago and is not here on Fridays as he’s on his way back to Chicago. The trickle down effect means that our VP of SALES isn’t here either. The precedent which is now set essentially gives ANYONE in the company the right to "work at home" on Friday.

The ability to actually work while working at home is a rare one. I’ve tried it. Doesn’t work. Too many toys at home to distract me. I’ve watched others try it, too… doesn’t work for them for a variety of reasons. There are people who are very good at working at home, but these tend to be the HYPERFOCUSABLE types who are also great assembly programmers.

Back to Fridays. The added benefit of these "work at home" Fridays is that the folks who actually make it in are distinctly aware of the folks who aren’t there which means they’re liable to slack or leave early. My rough estimate is that we’re losing roughly 20% of our productivity because Fridays have died.

Unacceptable.

Dead Fridays are truly only a symptom of a larger problem. THE COMPANY, like many small-ish start-ups who’ve made it this far, is basically waiting for other big companies to start buying software again. Few, if any, sales are coming in, so THE COMPANY has focused on getting the expenses under control, going through three layoffs, scrambling to get additional funding, and… waiting.

At the end of this waiting period there are two options. Either, become successful or die. I would argue the death of Fridays is a preliminary indication that others believe the die scenario is inevitable which means that the problem which actually needs to be solved is "belief that THE COMPANY will be successful".

If this is true, neither of the strategies above will work because both assume that an employee has something he/she is a) willing to work hard for (ie: unreasonable deadlines) or b) willing to defend (ie: against a mortal enemy).

First Entry

A friend asked why I didn’t have a weblog to which I replied the following,

… a few thoughts:

o In general, weblogs annoy me because folks haven’t spent the time to actually construct a coherent thought. They’re rambling… and rambling is good, but it’s generally an activity which occurs inside ones head. Rambling to OTHER people is generally received as "Uh, what are you talking about?"

o IT IS VERY LIKELY because of my predisposition towards weblogs that I am unfairly biased. Meaning, there are probably many worth weblogs out there, but since I found the first, say, 10 annoying, trite, and/or dull, I stopped listening.

o I LOVE TO WRITE. REALLY I DO. IF YOU DON’T WRITE IT DOWN IT NEVER HAPPENED.

And then I asked her some questions. And then I said,

“WITH ALL THAT SAID, I’ll start a weblog tonight. CALL IT A SOCIAL EXPERIMENT

The primary reason this is an experiment is because I’m using the JERKCITY brand as part of this weblog. This means folks are expecting me to go HGUAHGUAHGUBLBHAUGHUAH which I’m not currently planning to do.

My gut feeling is that a weblog is a CRY FOR ATTENTION and I get plenty of attention. People are walking into my office on a minutely basis asking, "Rands, solve hard problem X". And I do. I get to solve hard problems. My brain is engaged so there isn’t much excess energy to devote to a weblog, but YET HERE WE ARE.

Perhaps there is another reason for weblog. Perhaps a reasonably well thought out weblog will PREVENT aforementioned folks from ENTERING your office in the first place because you’ve already thrown the answer (whatever that answer might be) out into the world via the Internet.

This thought is a really restating point #3 above - "IF YOU DON’T WRITE IT DOWN, IT NEVER HAPPENED."

I buy that. I like that. Here’s another reason why writing it down will make you appear smarter than you actually are…

Rands explains how to solve hard problems

Hard problems are best solved by:

1) Thinking about the problem 2) Talking about the problem with others. This is the process I will call "cross pollination" or "hallway conversations". The goal of this phase to first acknowledge that you aren’t the smartest person on the planet and that others might be able to add value to your analysis of the problem. 3) Forget about the problem. You’re not actually NOT forgetting about it because your brain doesn’t let go of hard problems until some type of solution/resolution is reached, so we’ll call this "background processing". Sleep is a good way to do this and has the added benefit of decreasing emotional involvement with the problem.
4) Arriving at a solution. The beloved A-HA! moment. Pure synthesis. It rocks. 5) Writing the solution down. Writing it down is essential because, until this point, it’s very likely all you’ve done is think and talk about the problem. Writing it down forces you to arrange the solution (and possibly the problem) into linear steps. This act may reveal interesting aspects to the information that you couldn’t grasp when you were running around the building yelling at people about the problem. It also creates a document of your solution which means if you’re hit by a bus after you’ve come upon a cure for cancer that someone else can claim your work as their own and receive the Nobel Prize.
6) Repeat steps 1 thru 4 replacing PROBLEM with SOLUTION. This is error correction. Did you capture all the various intricacies of your solution when you wrote it down? How about that off-the-cuff conversation you had with SOandSO over a donut? Better make sure.
7) Executing the solution. Translation: FAME/GLORY/SATISFACTION/DINERO. It’s important to note that it’s difficult to execute this step if your solution blows. Alas, this is why this section is called HOW TO SOLVE HARD PROBLEMS and not HOW TO SOLVE HARD PROBLEMS WELL.

In any event, DO THIS FOR ME. When you have a hard problem, please bring me in at STEP #2. Thank you.

Hey, this weblog gig RULES.

Rands explains the deal with ALL CAPS

Because of Jerkcity’s NET_FAME, I’m granted a special dispensation when wandering around the IRC (NOTE TO FANS: #jerkcity is on #EFNET - IF YOU SEND ME MAIL WHAT #EFNET IS, I WILL IGNORE YOU - PROMISE). Translation: When I show up and starting RAMBLING IN ALL CAPS, most folks don’t immediately BOOT’n’BAN because they realize it’s MY JOB… usually.

Usually when I arrive in a channel and starting BLATHERING IN ALL CAPS, someone invariably asks, "What’s with the ALL CAPS"

ALL CAPS is generally viewed as yelling. Has been for as long as I’ve used a computer. (HINT: BBSes) What you should see when RANDS when shows up in his IRC guise and is speaking in ALL CAPS is that he is not really shouting… he’s using all caps to indicate sarcasm… stupidity… ignorance. These are tones which we easily discern when we’re 1:1, but we’re not right now, are we? I’m sitting here at my desk drinking SportTEA and YOU’RE SITTING HERE WONDERING HOW A GOOGLE SEARCH FOR ADMIRAL KRAG PORN ENDED UP WITH YOU READING JERKCITY.

The point is, yelling is reasonably easy to indicate with a keyboard. There’s a even a key for it — it’s called an exclamation point.

"You suck dick!"

What typographic means do we have to indicate sarcasm? A smiley? That’s way gay. I claim that caps is the solution. It’s elegant and you don’t have to remember WHICH PARENTHESIS TO USE.

MARISA TOMEI SUCKS DICK.

Now, Marisa doesn’t really suck dick or maybe she does… that’s not the point… the point is, compare the ALL CAPS version to the HONEST AND TRUTHFUL version.

Marisa Tomei sucks dick.

HOLY SHIT? SHE DOES? LORD GOD HEADING TO HOLLYWOOD/THE OSCARS FOR STARSTUDDED BLOWJOBS.

(c) 2002-2010 Rands  (Made you look)