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