Management Start here

The Rands Test

It’s hard to pick a single best work by Joel Spolsky, but if I was forced to, I’d pick The Joel Test. It’s his own, highly irresponsible, sloppy test to rate the quality of software, and when anyone asks me what is wrong with their team I usually start by pointing the questioner at the test. Start here.

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

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

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

12 Points

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Easier said than done, Rands.

Ok, don’t say it’s stupid.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Are you actively killing the Grapevine? (+1)

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

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

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

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

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

Magnitude and Direction

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

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

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

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

# October 11, 2011 : Twitter : Comments (13)
Management Dream then act

Fred Hates It

Management has a set of power words that it’s appropriated as a means of giving it a sense of identity. This list is endless and entertaining. When these words are spoken, they are said in such a way that you are meant to wonder in awe, “What does that mean?” but you don’t ask for fear of looking like an idiot.

Today’s word: off-site. An off-site is a… meeting. There are some specific characteristics to an off-site, but all it is a meeting with a group of people that likely lives up to its name in that it’s elsewhere, it’s off-site.

Now that you understand what it is, let’s understand why you might hate it.

Why I Get in Fred’s Face

The reason an off-site exists is simple: you, the leader of the people, need certain essential work to occur that cannot easily occur now under normal conditions within the building. It’s a little sad. When it was only 20 of you, each of three different off-sites I’m about to describe would just happen… organically. Fred would stand up in the middle of the office and say, “Ok, we need a new UI framework. I’m going to do it, and anyone who wants to get in my face needs to do it now.”

So you got in Fred’s face. You argued. You debated. Fez and Phil jumped in and in 17 very important minutes, you fundamentally changed the UI architecture of the product.

At an organizational size that varies for every team, natural cross-pollination and communication activities that used to happen organically, that allowed for cultural and strategic work to get done, and allowed for big decisions to be made, can no longer occur. The team can no longer look around the room and get a sense for how everyone is doing because there are too many everyones.

Zeitgeist has become diluted. Random hallway error correction doesn’t happen because the right folks aren’t bumping into each other. It’s sad especially for the folks who vividly remember standing up and getting in Fred’s face. You need to recreate the space and place where a team can bond, a strategy can be devised, or you can begin an epic journey.

You need a well designed off-site.

Who We Are, What We Need, and Our Epic Journey

The reason you invoke the off-site is going to vary from group to group. The following are three specific scenarios where I believe you need to employ the off-site, but there are more.

We need to understand who we are. If you’re familiar with my writing, you’ll know I don’t think you really know what the hell is going on in a team for 90 days. You have moments of comforting clarity during the first three months, but you don’t really know all the moving parts until a chunk of time has passed. Now, multiply that early confusion by every single person who has been hired in the last nine months.

During times of rapid growth, a team doesn’t necessarily take the time to stop and get to know each other because they arrive and the first thing they notice is, “Whoa. Everyone is in a big fucking hurry, so I must hurry as well.” Their normal instincts regarding getting to know those around them are buried in their goal of being recognized as a person who is also in a hurry.

You need an off-site not to solve a strategic product problem, but to give the team time away from their hurry to get to know each other. Socialization will happen via each of the off-sites I’m about to describe, but the need for a team to understand itself is a cause worthy of an off-site all by itself.

We need a new direction and/or we need fewer disasters. Something significant is broken. Either disasters are occurring and the normal processes of detection and correction aren’t working, or everything appears to be working but we’re not achieving success — for whatever success means at that stage of the company. In either case, the status quo represents a legitimate threat to the company.

The purpose of this off-site is deep brainstorming. The group is tasked with discovering and refining ideas, proposing experiments to test these ideas, and finally stepping up to run with these ideas back at the ranch.

We are embarking on an epic journey. Nothing’s broken, it’s just time to start. This last off-site might also be called a kick-off meeting. You generally know what you want to do and when you want to do it, but need all the leaders responsible for making it happen to be in agreement about where you’re headed and why.

This off-site is an alignment meeting. Strategy can be discovered as part of this meeting, but that isn’t the primary goal. You are collectively pointing folks in the correct direction (this is where we’re headed) and defining the urgency (and this why we’re headed there).

A Meeting with Certain Characteristics

While an off-site is just a long meeting, it is a meeting with certain characteristics that differ from your average daily meeting. I’ll explain each and I’m going to bring Fred along because Fred has no problem telling us exactly what he hates.

By definition, you can’t invite everyone. Remember, the reason you need an off-site in the first place is that the team has grown to a size where they are consumed by hopefully essential tactics. They don’t have time to step back and think about later because from the moment they walk in the door, there are meetings, phone calls, emails, and interviews that simply must happen. Everyone is consumed in the work. Yes, the individual has a free hour here and there to take a deep breath, but collectively the team doesn’t have time to figure out what it is thinking or why they are working so hard.

Depending on the goal of your off-site, you need to pick the people who are both capable and willing to solve the hard problem sitting in front of you. If you’re trying to understand who you are, you invite every person that you want to know. If you want fewer disasters, you invite both the folks creating them and those with the ability to fix them. You need to be able to look around the room and confidentially think, These are people to solve the problem.

Fred hates it. He says, “Man, why are we being exclusive? I want everyone to weigh in on the important decisions that affect the company. We’re all shareholders and we should all get a vote.”

There’s a name for a meeting where everyone is invited, Fred. It’s called an all-hands and if the all-hands isn’t part of your regular company meeting regimen, I can see why you’re pissed. However, your all-hands is 120 people and my question is: when is the last time you saw 120 people efficiently propose, debate, and then make a decision? An off-site is not an opportunity to ignore opinion; an off-site is a chance to select a group of folks who are going to best represent the company on whatever huge problem we’re solving. Yes, the selection process is hard.

Everyone presents, or at least speaks. Once you’ve got an initial list of folks, ask yourself this: “What appropriate presentation would I ask each invitee to do?” My rule of thumb is that each person at the off-site has a deliverable, and that usually means that they need to step up and present. This exercise teaches me two things. First, if I can’t think of something I’d want this presenter to talk about given the problem at hand, why are they invited? Second, I start to see duplication. Well, Sarah and Frank are both great about talking about our lack of design process. Do I really need them both?

This isn’t a hard rule. There are many times you need to invite folks simply because you know they’ll speak up randomly and brilliantly. However, as you’re building your off-site, this step illuminates both your agenda and your audience.

Fred doesn’t really hate this because he likes the democratic and flat feel it gives to the affair. Thanks Fred.

It’s not in your usual building. The other word frequently associated with off-sites is “boondoggle”. When you learn that the senior leadership team is spending the weekend in Vail, I can assure you, yes, that is a boondoggle. I’m certain there is a clear business justification that explains why the company needed to fly seven executives to Vail in the middle of fall, but I’m also certain they could do the same work at a lower altitude.

Off-sites don’t need to be swank, they need a sense of elsewhere. They need to be far from the tactical distractions of the office because they need a new view. One of your goals for an off-site is to create grounds where people feel comfortable speaking heresy. If whatever problem sitting in front of you could be solved via the day-to-day, it would’ve been solved. Drastic measures call for creative thinking, and now that you’ve gathered these bright people together, you want them to feel comfortable saying whatever compelling ideas cross their minds. Speaking heresy is easier when you aren’t surrounded by visual reminders of obvious constraints.

Fred hates it. “Do you know how much this is costing us? We could do exactly the same thing in the 7th floor board room.”

Yes, we could, Fred, but within two hours here’s how it’ll play out: someone is going to figure out we’re hiding out in the boardroom and they’re going to find something that appears to be earth-shatteringly important that will pull one of us out of the room. Folks will return slowly from breaks and sometimes won’t return at all. You are paying a premium to make sure everyone in the room can focus, but if you have an off-site worthy topic, it’s a small price to pay for this group’s attention.

There’s someone responsible for flow as well as action. With the correct group in the room, getting a healthy conversation started on the problem isn’t hard. In fact, once the group gets started, the issue will be figuring out how to get them to stop. To manage this, there are two roles you need to designate before the festivities begin: a Master of Ceremonies and a Taker of Notes, and they are usually not the same person.

The Master of Ceremonies is the person responsible for not just moving the day along, but also knowing when to stop and pivot. Again, getting this particular group into a healthy conversation shouldn’t be hard, but don’t confuse a healthy conversation with progress. A deeply engrossing conversation is a great thing and a target rich environment for finding the core of a great idea, but there are many conversations to be had and this is just one. A good Master of Ceremonies knows when an idea has been explored as best it can and it’s time to move on.

The Taker of Notes reads like an administrative job, but it’s the most important gig in the room. Once an off-site really gets going, once the team really engages, it’s all going to sound like great ideas. The Taker of Notes is tasked with not only capturing the bright ideas, but the right ideas. After years of off-sites, my observation is that you only find three new ideas that you act upon. These can be huge company-changing ideas, but there are only going to be three and it’s the immense burden of the Taker of Notes to not only find them, but assign them to the people who can and will drive them forward.

Fred hates it. “They’re messing with the flow… man. Why can’t we just have a conversation? A debate? Why are we on the clock?”

Fred, I understand that you hate process. You equate the appearance of process with a decrease in free will. You believe that process is going to slowly going to sap this company of the creative ninja spirit that got us from 12 to 120 people and you’re right. Blindly landing process without considering the culture it needs to support it is a recipe for disaster. However, believing that the loosey-goosey make-it-up-as-we-go rebel spirit that got us to 120 is going to take us to 2000 is absurd.

I believe each time your company doubles in size, it needs to reinvent how it communicates, and each subsequent transformation is increasingly radical and foreign. Fred, if we’re going to grow we need to constantly reinvent ourselves.

No personality tests, no trust falls, and no outsiders. There are a couple of traditional moves that well intentioned folks who have attended off-sites elsewhere are going to suggest, but that I want you to avoid:

Fred, not surprisingly, is actually cool with all of this, too. Thanks again, Fred.

They need to sleep on it. There’s a moment I like each person to have as part of an off-site and I call it the bright and shiny inflection point. At some point after a compelling talk or brainstorming session, they start to believe. They finally let go of all the tactical things they need to do and allow their brains to jump into the creative soup that the organizers have been vigorously stirring. They see beyond the week and begin to see the next year. They have epiphanies and they start to see the beginnings of solutions to complex problems that have been nagging them for months.

How do you get them there? You’ve go to get them soaking in it and that takes time. An off-site must be at least two days. You need one evening where they get away from what is hopefully a high bandwidth conversation regarding whatever it is that ails the company, and get a chance to process this conversation in the back of their heads. When they walk into the unfamiliar location the next morning, whether they’ve mentally made progress or not, the big huge problem is still sitting there on the white board waiting to be attacked.

Fred hates it. “Since when do we need to spend two days solving this one problem? This company was founded by two guys high on Diet Coke at the Creamery. We had a prototype in a week and that prototype was live the week after.”

Fred, the curse of success is that we move slower and it’s a confusing curse. See, we’ve been successful and the result of that success is that we’re able to hire more people to do the seemingly impossible amount of work our success has created. But each person we add to do more work strategically slows us down. Each additional person levies a communication tax and unless we figure out how to constantly improve our communication, we’re just going to get slower. That’s why we’re here; even if perfect solutions came to us during caffeinated highs, we’d still need to vet them with the many bright people we’ve hired to help us grow.

What Fred Really Hates

The morning that Fred arrives at the off-site, which is at some nearby location, and after a delightful breakfast, Fred and the rest of the off-site team gather in a room where someone important stands up at the front of the room and starts talking. As the morning’s coffee kicks in, Fred’s initial knee-jerk reaction to this talking is, “You know folks, I have essential stuff to do and this yap-yap-yapping isn’t helping me get this stuff done.” Fred folds his arms, clenches his jaw, and resigns himself to simply waiting until it’s over so he can get back to important work.

At some point during the first day, Fred silently has his bright and shiny inflection moment. He turns off his phone and furiously start scribbling down ideas. That night at the off-site dinner, the conversation is about work, but it isn’t about the shit he’s been slogging through daily, it’s about the strategic work he could do to make that shit go away — forever.

And then it’s over. Fred returns to the office and he’s pumped and ready to start changing the world, but the moment he walks in the door, everything he hasn’t done is staring him in the face. As he starts rebuilding his daily work context, he realizes, “Not only do I have a lot to do, but now I’m behind.” The bright and shininess of the off-site he’s retained fades quickly.

A week passes and now he’s angry. He’s angry because now that he’s caught up, he’s never going to get ahead because no one is making any time for him to apply all of his bright and shiny epiphanies. In fact, after a week, nothing from the two day off-site has survived except Fred’s lasting opinion: “Well, that was a waste of our time.”

The successful off-site is one that maps the discoveries of the off-site to the reality of the work. Bright and shiny inflection points are full of energy, but unless that energy is carefully channeled back into the building and immediately acted upon, all an off-site represents is an frustrating opportunity to dream, but not to act.

# September 12, 2011 : Twitter : Comments (6)
Management their productivity is your productivity

Bored People Quit

Much has been written about employee motivation and retention. It’s written by folks who actively use words like motivation and retention and generally don’t have a clue about the daily necessity of keeping your team professionally content because they’ve either never done the work or have forgotten how it’s done. These are the people who show up when your single best engineer casually and unexpectedly announces, “I’m quitting. I’m joining my good friend to found a start-up. This is my two weeks’ notice.”

You call on the motivation and retention police because you believe they can perform the legendary “diving save”. Whether it’s HR or a well-intentioned manager with a distinguished title, these people scurry impressively. Meetings that go long into the evening are instantly scheduled with the disenfranchised employee.

It’s an impressive show of force, and it sometimes works, but even if they stay, the damage has been done. They’ve quit, and when someone quits they are effectively saying, “I no longer believe in this company”. What’s worse is that what they were originally thinking was, “I’m bored”.

Boredom is easier to fix than an absence of belief.

Detecting Boredom

There are many reasons other than boredom that someone will quit. Your company might suck or be headed towards suck. This person might randomly get an offer that fulfills their life’s dream. There is a bevy of unpredictable reasons that someone will leave, but boredom is an aspect of their daily professional life you can not only easily assess, but also fix. More importantly, boredom is not initially catastrophic. Boredom shows up quietly and appears to pose no immediate threat. This makes it both easy to address and easy to ignore.

My three techniques for detecting boredom:

  1. Any noticeable change in daily routine. A decrease in productivity is a great early sign that something’s up, but what you are looking for is any change in their routine. Increased snark? Unexpected vacations? Later arrivals? Earlier departures? Anything that strikes you as out of the ordinary for someone whose day you are familiar with is worth considering. The root cause of this change may have nothing to do with boredom, and the best way is figure that out is…

  2. You ask, “Are you bored?” Even if you don’t have a gut feeling, it’s a good question to randomly ask your team. When I ask, I look you straight in the eyes and if you can’t stare me in the face and answer, I’m going to keep digging until you look me in the eye. Remember, the goal here is to discover boredom before they know it, and the act of a simple question might be just the mental impetus they need to see the early signs in themselves.

  3. They tell you. And you listen. You’d think that someone walking into your office and stating that they’re bored would set off all sorts of alarms in your head, but that’s because you’re halfway through this article wondering when I’m going to cut to the chase and explain how to fix bored people. The reality is that someone is going to tell you they’re bored quietly and when you least expect it. They’ll tell you halfway through your 1:1 and they won’t use the word bored. They’ll say something innocuous like, “…and I really don’t know what to do next,” and you’re going to blow right by the most important thing they’ve said in a while because you’re worried about your next meeting.

As I’ve reflected on the regrettable departures of folks I’ve managed, hindsight allows me to point to the moment the person changed. Whether it was a detected subtle change or an outright declaration of their boredom, there was a clear sign that the work sitting in front of them was no longer interesting. And I ignored my observation. I assumed it was insignificant. He’s having a bad day. I assumed things would just get better. In reality, the boredom was a seed. What was “I’m bored” grew roots and became “I’m bored and why isn’t anyone doing anything about it?” and sprouted “I’m bored, I told my boss, and he… did nothing,” and finally bloomed into “I don’t want to work at a place where they don’t care if I’m bored.”

I think of boredom as a clock. Every second that someone on my team is bored, a second passes on this clock. After some aggregated amount of seconds that varies for every person, they look at the time, throw up their arms, and quit.

A Boredom Plan of Action

Whether someone is bored or not, you always need to be able to answer two questions regarding each person on your team:

  1. Where are they going?
  2. What are you currently doing to get them there?

In your head, answers sound like this:

Knowing the answers to these questions makes the rest easier, but if you don’t have answers, you can start figuring them out by:

Don’t Forget What It’s Like to Build a Thing

This piece might read like I believe that engineering is some privileged artisan class and that I’m overly protective, and that is exactly what I believe. My gig is the care and feeding of engineers, and their productivity is my productivity. If they all leave, I have exactly no job.

Part of your credibility as a leader is your public and repeated declaration that it’s your job to help your team succeed, but you have another task: you need to keep building stuff.

I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored.

# July 12, 2011 : Twitter : Comments (85)
Management Everyone wants to grow

DNA

Flat. It’s an organizational meme in rapidly growing teams in the Valley and it contains a couple of noble ideas. Simply put: a flat organization is one with as little hierarchy as possible to encourage the individual voice. What’s not to love?

The first challenge to the flat organizational mantra is the inevitable arrival of leads or managers tasked with organizing different aspects of the team. The flat religion’s answer to this development is rebranding of the role: the lead or the manager is no different than the individual. It’s not a promotion, there is no raise; it’s just a different gig. There is no difference between those responsible for building the product and those responsible for building the people.

I love this. I love this because it’s the beginning of solving a core career problem in teams of engineers: how do we grow? As I wrote about in Being Geek, the Curse of the Silicon Valley is that great engineers are often promoted to leadership for their hard work. While many succeed in this role, an equal part fails because the skills required to lead are vastly different than the ones required to be an engineer. The Curse is that we’re often placing our most valuable engineers in a role where they’re predisposed to fail.

Think of it like this: there’s a large population of immensely talented engineers that should not be leaders. There is no amount of training that would make up for the talent we’d extinguish by teaching them how to write annual reviews.

But everyone wants to grow.

Unfortunately, in many companies the only perceived growth path is via management. Yes, there are job grades and cleverly phrased job descriptions that confusingly define the various states of engineering experience and growth, but these are a joke. These are a distraction packaged as a solution to the fact that we don’t have a good idea how to systematically grow engineers outside traditional management hierarchy.

No Ticker Tape Parade

A solution begins with rebranding, by introducing the idea that managers and engineers are hierarchically no different. Keep the pay the same; don’t throw a ticker tape parade when a new leader is minted. They are peers. I support this religion because a flat organization is one where power, accountability, and responsibility are equally distributed. But I do not yet understand how this idea scales.

Even with leads and managers who have the best of intentions, the moment they become responsible for folks — the moment everyone realizes they sign the checks — the relationship changes. I can’t yell at you because you sign the checks. This core change of perception isn’t just based on compensation, it’s based on a change of ownership and responsibility and it’s the beginning of all sorts of potential cultural turmoil that’s worthy of an entire other article.

We need leads and managers as a means of scaling responsibility and communication, but we need dispel the idea that this is the only growth track for engineers.

I offer: the DNA meeting.

Five Kinds of Win

DNA stands for Design’n’Architecture. At its core, DNA is just a meeting. It’s a collection of bright engineers from across the team or the company sitting in a room tasked with a specific purpose. As the name suggests, they are responsible for deep analysis regarding decisions and directions core to the product. You probably already informally hold this type of meeting right now when faced with a big technical or design challenge. You gather together an informed set of eyeballs to vet the challenge. DNA makes the informal formal and it has five kinds of win:

  1. Shining a light brightly. While the more eyeballs you get on any decision the better, the DNA is scheduled when something technical is going down. Something big. Something of magnitude. It’s not a bet the company decision, but it might be a bet the group — or the division — decision. If we fail at this, the consequences are extreme. This is why when DNA is going down, you…

  2. Bring respectable firepower. We’ll talk more about the construction of the DNA team in a bit, but I want you to think of the three best engineers around you. I’m not talking just about ability, but also the folks who go out of their way to teach. The engineers who not only know what they’re talking about, but have the ability to explain this thinking. They shine a bright light on the idea by making the complex painfully obvious. The DNA team is the set of engineers who are not only the best candidates to vet the big idea, but they have ability to talk about how to make it better, can constructively criticize, and are distinctly drama and politics-free. See…

  3. Teeth. You can gather all the talented engineers you want, but what will make the meeting useful and memorable are two threats. First, the rule for all attendees in a DNA is: if you don’t contribute, you won’t be invited back. DNA is not a regular meeting; DNA is an active and healthy debate about a bet big enough that we’re gathering our bright minds to make sure we don’t fuck it up. If you’re in the room, it’s because we believe you have something to add and if you don’t, we’ll correct our misperception.

    Second, it needs to be culturally understood that if you don’t bring your A game to DNA, the team is authorized to mentally kick the shit out of you. The end result of a healthy DNA will have members of the receiving team sitting with their heads squarely planted on their desks, whispering, “Oh shit, I can’t believe we didn’t think of that”.

    DNA is not cruel. DNA is a living, breathing example of a team of engineers who put the value of design and technical excellence above all else. They don’t rule by mandate, they influence by being great at what they do. At the prior gig, the threat of DNA pushed us to prepare in extraordinary ways. Our goal was to predict every single question DNA might ask and have every answer in our back pocket. Winning in DNA was silence.

  4. DNA has absolutely nothing to do with management (and everything to do with leadership). Pure managers are not considered for the team because DNA is about cultivating technical leadership. A DNA meeting is a staff meeting of the influential engineers who don’t want direct reports, but they want to lead. If managers have anything to do with DNA, the meeting will become about the managers and not the technical leaders.

  5. DNA is achievable and aspirational. Inclusion on the DNA team is not a popularity contest. It is the end result of a well-defined journey that any engineer who is interested can embark upon. At the prior gig, it was a combination of tenure and experience, shipped products, and visible technical contributions to the team. Some measures will be subjective, but the end result is that when someone arrives on DNA, everyone would agree, “Yeah, they belong here…” It’s not a club; it’s an honor. DNA recognizes team members who we want as examples of folks who live and breath technical experience, who are selfless, and who contribute exceptional value to the company. DNA exists as an acknowledgement that a team is led not just by the folks who build the people, but also by people who build the product.

Flat is a State of Mind

I didn’t come up with the idea of DNA. It was a former boss at the mothership who suggested the idea long before I arrived on the team. Since then I’ve adapted the idea twice, and each adaption has yielded different results. In the current gig, we split DNA into different tracks: UX DNA and System DNA. The UX engl cue to everyone that all forms of leadership matter.

[Update] There are questions regarding DNA in the comments. I’ve answered a bunch of them and want to repeat a key point: You build a DNA to suit your culture. Think of this article as describing the broad strokes of how to build a regular meeting that serves as the technical conscience of the group.

# June 29, 2011 : Twitter : Comments (20)
Management Learn schmearn. I'm a genius.

Lost in Translation

Early on in your mastery of a complex thing you are going to catastrophically overestimate your ability.

Your confidence is going to be artificially high. This new job, hobby, or sport is going to appear magically easy. You’re going to feel gifted. Those watching your miraculous aptitude keep saying, “beginner’s luck”, but that’s neither what you’re hearing nor what they’re saying. What you’re hearing them say is, “We are jealous that you are gifted at this thing you totally don’t understand”, but what they’re actually saying is, “We understand it’s intoxicating to instantly feel like an expert and we will most certainly bite our tongues when you painfully discover how much you have to learn.”

Learn schmearn. I’m a genius.

The gift of the enthusiastic beginner is blissful and empowering ignorance. They are not burdened with the depth and complexity of understanding; they shine brightly with enthusiasm… until the Fall.

Wallace Hates Me

I wasn’t even a manager. I was a lead of two engineers, but titles don’t matter. It was the change in attitude of one the engineers that got my attention. Harold didn’t miss a beat after I became his lead. He was in my office on Monday morning: “Where do we start?”

“Maybe we should, uh, fix error handling in the test framework? Maybe?”

“It’ll be done by Wednesday”. Cool. I can so do this.

Wallace was indifferent. I waited until Wednesday to walk into his office to ask, “Hey, I was wondering what you were working on?”

“Same as last week. Endless bugs.”

“Ok, great… super. Uh, holler if you need anything, ok?”

Silence. Ok, fine. I’ve never really gotten Wallace, he’s done his own thing and he seems to do it well, so let him do it, right?

Besides, I was a lead. Look at Harold — he bolts into my office every morning in his bright orange Philadelphia Flyers jersey and asks the same question: “What’s next?” He and I were cranking, so much so that three weeks after I became a lead, they added Stan to the team. Stan was a Boston Bruins fan, but he and Harold were birds of a feather. They grabbed coffee together in the morning, argued about hockey, and then darted to my office: “What’s next?”

I can so do this.

Three weeks turned into three months and Harold, Stan, and I were nailing it. Yes, I’d dutifully check in on Wallace each week, but the action was with the three of us. I figured when Wallace was ready to climb out of his shell and join the productivity party, he would.

Three months to the day, my boss walked in my office with a paper in his hand. “Wallace has been keeping a daily log of every interaction with you and claims, outside of meetings, that you’ve collectively spent 30 minutes with him in the last three months. Is that true?” He handed me the paper:

Six pages of meticulous, single-line entries documenting every single minute of my managerial incompetence. My thought: “I thought he didn’t care.”

It’s called the Fall because in an instant the normally predictable floor upon which you stand vanishes and you enter a mental free fall where you feel like throwing up because you no longer know which way is up.

The Fall is Not the Lesson

The sensation of the Fall is disproportionate to the size of the lesson. You experience not just the sense of failure, but also the colossal irrational disappointment that you are no longer an expert at this task with which you have no previous experience — which is goofy. Here’s the kicker — you now have just enough experience to understand the actual work involved in becoming proficient at a task you previously thought you could magically improvise.

A Wallace-class Fall is common with freshly minted leaders and it’s one exacerbated by the commonly introverted tendencies of engineers. It’s the discovery that not only is someone you lead not following, but that there is a complete and total personality disconnect with this person. None of your usual networking moves work. They stare blankly at your witty repartee and when they do talk, it’s as if they haven’t heard a single word you’ve said.

It’s a frustrating discovery because part of the reason you became a leader was due to your natural and proven people skills. But it’s an enviable discovery because on a planet full of people most of them aren’t like you and your first Wallace will not be your last.

Your Instincts are 100% Wrong

A complete personality disconnect with someone you intend to lead, like in a Wallace situation, is rare, but for the sake of figuring how to tackle it, let’s assume this is the worst case scenario.

In a normal getting-to-know-you situation with an employee, the first question I want to be able to answer is: “What do they want?” What is their core motivation with regard to their current gig? Are they working on a promotion? Are they just figuring out the gig? Are they adrift? Are they ok with being adrift?

Understanding core motivation does not give me a complete picture of a person, but it gives me a place to start. When I know where they want to be, I can start to figure out how to get them there. Unhappily adrift people want immediate action. Those seeking promotions are eagerly seeking opportunity and will own anything to get it. However, this is Wallace and Wallace stares blankly when I blithely ask, “What floats your boat, Wallace?”

Give up on the idea that you’re going to finesse Wallace into telling you his secrets. Nothing that comes to you naturally is going to work with someone who honestly believes you are an alien. Your first job isn’t understanding core motivation, it’s basic communication.

In any situation where communication is suspect, I rely heavily on clarification. Whenever I say something that might be ambiguous, I ask, “What did you hear?” In return, when I’m listening and the topic or intent is not abundantly clear, I restate, “Ok, what I heard was…”

It sounds like this:

Me: “… and new requirements came in this weekend, but Jennifer still wants to see an initial spec by Thursday. Wallace, what did you hear there?”

Wallace: “Jennifer wants a spec on Thursday.”

Now, if this was Harold or Stan, we’d be done. A verbal commitment was made and we’d move on, but this is Wallace and I can assume nothing.

Me: “Yes, a spec on Thursday. And what does that mean for your work?”

Wallace: “I was planning on finishing doc review on Monday and building out test data on Tuesday and Wednesday. I won’t get to that if Jennifer needs a spec on Thursday.”

Me: “What I’m hearing is that you’ve got a pile of work that will need to be rescheduled, right?”

Wallace: “Right.”

Me: “And if we do that, do you think you can have the spec done?”

Wallace: “Maybe.”

I know it feels like the passive aggressive Olympics, but I swear this is how Wallace thinks. In his world, a work commitment is never implied and must be verbally stated. We need to go back and forth until he states, “I will reschedule all of my planned work from this week until next week. I’ll relay the implications of these changes to the docs and QA teams and I have moderate confidence there will be no issue in delivery of a first draft of the revised spec by close of business on Thursday.”

It’s pedantic, annoying, and inefficient, but when personalities are disconnected, you don’t know how to communicate, so that’s where you start. With practice, you’ll learn the unique rules of engagement. You’ll discover the words and the ideas they use to describe both their happiness and their displeasure. You’ll learn the visual and verbal tells they employ when they have no idea what you’re talking about. In time, you’ll develop a mental map of this person who is decidedly not you.

The sensation of interacting with these aliens will never feel natural. It will always feel deliberate and foreign, but practice will provide you with a guide into how they think and a map that might provide insight for you into what they want.

The Size of the Lesson

It took months. It took months of conscious and intentional conversations with Wallace for us both to subconsciously agree to a communication peace treaty. It was painful — each time Wallace and I would drop into that primitive conversation dance, Harold and Stan would stare at each other and shake their heads — This nonsense again?

The nonsense was the essential lesson I learned from my first managerial Fall: when communications are down, listen hard, repeat everything, and assume nothing. The Wallace situation was the first of many Falls, and the beginning of understanding something fundamental to make future Falls less catastrophic: that people are the best puzzles you’ll never solve.

# May 23, 2011 : Twitter : Comments (21)
Management Drastic measures may be necessary

Three Superpowers

Phil’s team is adrift.

Phil is smart and meeting-friendly, but he’s a crap people manager and that crappiness is slowly poisoning his team. You know how bad it is because the star of Phil’s team finds ways to schedule meetings with you where the story is always the same: “He’s smart, but he is genetically incapable of managing people. We’re three weeks away from full-on revolt unless something changes.”

In the field, Phil’s team waits… waits until whatever impending disaster has fully arrived before they grudgingly say, “Well, ok, huh, we should probably handle that… now?”

Frustratingly and confusingly, 1:1s with Phil feel like progress. He says all the right things. He accepts responsibilities for failures and articulates compelling next steps that he assures you will improve the situation. But there is a wide strategic gap between those meetings and Phil’s daily management judgement. The actions do not match the words, and each Monday morning arrives with the realization that Phil still isn’t getting things done, the stars on his team are about to quit, and I have no idea what to do.

You need a new superpower.

Three Superpowers

You have a natural management state. This is the default state that is the foundation of how you make your decisions, the tone with which you run your meetings, and the personality you wear as you talk in the hallway. The state has served you well; you’re comfortable with it because it is you.

Unfortunately, this natural state is the source of your Phil confusion. Your natural state is blinding you to the obvious course of action. Your instincts are wrong. You need to be someone you are not to radically change your perspective.

Here are three personalities, each with their own perspective, and, more importantly, their own superpower:

The Machine has the Debate

The Machine. Our classic mechanic. Her mantra is: “Without a plan, there is no hope.” She’s convinced that the whole world is measurable. She follows the process because only by the strict adherence to the process can we truly generate a meaningful measurement to clearly understand whether we are winning. The Machine’s understanding of the process and the necessity of it are unparalleled. The Machine loves to debate; she loves to consider all options, but when she’s decided — it’s over — there’s no changing her mind.

When the Machine wants something done, she uses The Debate.

The Debate starts with data. Each of you. Please explain to me in excruciating detail the last 10 incidents of Phil being an incapable people manager, and understand that I will ask follow-on questions until our understanding is complete.

The Debate continues with hypotheses. Synthesizing our cornucopia of data, I put forth the following hypothesis entitled “Three things we shall do to improve the Blight of Phil”. I expect everyone involved to challenge these hypotheses. But be warned, argument based on feeling rather than fact will be terminated.

If a hypothesis is successfully defended, it becomes the law and the debate is over. If it fails, the debate continues. A well-run debate results not only in the truth being vetted, but, more importantly, a consensus being built around this truth, which sounds delightful except for these caveats:

This is why…

The Jedi Master has the Nudge

The Jedi Master has magical people skills. His mantra: “Help me help you”. He’s all about the health of the people. He says, “People are our most valuable resource.” He’s conflict adverse because conflict is, like, a buzz kill… man. He wants to be your bud. His conflict avoidance has given him a healthy paranoia, but he buries that paranoia in a pleasant veneer of caring. He listens with intent and usually gets his way, but you’re never quite sure… how.

I’ll tell you how — the Jedi Master employs the Nudge.

You won’t even see the Nudge coming. In fact, you’ll be hard pressed to figure out when it actually occurred. The Jedi Master will say something innocuous, “Phil, what do you think of the design of Project X?” Rather than jumping on the question, Phil sits there staring blankly. He’s chewing on… something. If you could hear what Phil was thinking… The design? The design was signed off two months ago. It’s done. Why now? Is it because design was something we talked about in my annual review? I’m sure it is. Why do I feel like I’m missing something? I need to talk to the design team. Now.

The Nudge is the smallest, most viral piece of constructive feedback you can give. It is small enough to appear unthreatening, but it has enough intent, enough implications, that it plants itself in the receiver’s mind and can’t help but evolve.

The processing of a Nudge takes time — that’s the point. The receiver of a successful Nudge suspects they have a hint of a something, but they have no specifics. They have potential and there’s no telling when they’re going to turn that potential into action, but when they do, the action is all their own because they’ve done all the work. And that’s the point.

A well-constructed Nudge is a clever combination of everything you learned about people, leadership, politics and the person you intend to Nudge. It’s the delicate selection of a simple idea intended to slowly reveal a larger intent to someone who, in this case, will not hear the truth from anyone except themselves.

A well-placed Nudge is a goddamned managerial work of art. A poorly placed Nudge is a terrific way to get in trouble with your team:

Drastic measures may be necessary, so…

The Dictator has the Mandate

There’s the Dictator. His mantra is: “I’m the one who’s telling you how it is.” It’s his way or the highway. No one contradicts. No one argues, and while his imperatives are subtly molded and messaged as they are passed through the organization, he is oblivious to these small changes because from where he sits he believes directives are followed — word for word. The Dictator is allowed to exist because no one argues the fact that he gets results.

The Dictator’s superpower is the Mandate and it sounds like this: We all are climbing that hill right now and we’re not going to stop climbing that hill until everyone is at the top of the hill. Start climbing.

And everyone does. There’s no Debate. There’s no Nudge. Even the avid non-hill-climbers drop everything they’re doing to start merrily climbing as they sing, “We, the climbers of the hill, what a thrill.”

The power of the Mandate is alluring. It requires none of the laborious cat herding involved in managing the Debate. It eschews the subtle inner dialog required in constructing just the right Nudge. The Mandate is immediate, undisputed action, and when misused the Mandate can get you killed.

When you employ the Mandate, you leverage a large part of your credibility. You’re effectively saying, “Shut up and go,” and if where they end up isn’t where anyone expects, you’re less of a leader than when you started. This is an important fact that actual Dictators have forgotten. They believe that pure charisma — absolute, unwavering confidence — is all you need to fuel a Mandate, and while there are those who are just happy someone made a decision, there is an equal number of folks ready to kill you.

Dictators are killed. The consequence comes with the title. It’s not a messy death, it’s a professional one — it’s your employees ceasing to listen to you and eventually leaving when you’ve completely eroded your credibility or it’s the Board of Directors simply taking care of business when you’ve brazenly demonstrated you can’t.

My Favorite Superpower

These are stark examples of leadership stereotypes, and while you might see aspects of you or your management in these colorful descriptions, it’s more likely that each is already a part of you. You have a tendency to be a Jedi Master, but when cornered, you’re the Machine. The Dictator can serve you well, but it leaves your Jedi Master feeling… cruel.

The solution to your Phil problem is likely not a single power move, but all of them — at the appropriate time. While the Dictator mandates a comfortably clear, “Fire Phil”, the Jedi Master suggests, “Who does Phil communicate best with on his team? What can they tell you about him? How can they inform a Nudge?” which leads you to my favorite superpower — the Debate. While it’s not immediate, and the final Phil call is yours, it supports my core belief that an idea only gets better with more eyeballs.

# March 7, 2011 : Twitter : Comments (10)
Management They're not bitter - they're informed

Managing Nerds

Ten years ago, the world was collectively freaked out by the Y2K bug. The idea was that when innumerable software-driven clocks flipped at midnight from 1999 to 2000 that the digital shit was going to hit the fan. I blame the origin of the world-wide freak-out on the nerds.

Y2K collectively freaked out the nerds because every single software engineering nerd has had the moment where he looked across the table at someone important and said, “Yeah, I fixed that problem, but I have no fucking clue why it’s working. It’s a total mystery.” Nerds have been repeatedly bitten by previously dismissed and seemingly impossible edge cases that we believed there was no possible way for a regular human to encounter.

We’ve been shocked how often a demo has become a product. We know that it is an inherent property of complex systems that they will contain both our best work and our worst guesses.

I call this state of mind the Nerd Burden. It’s a curse put upon nerds who know how a system works, and, more importantly, what it took to build. Understanding the Nerd Burden is a good way to get into a nerd’s mind and start to figure out how to manage them.

A Worst Case Scenario

This is an article on nerd management. The usual requirement of nerd management is that in order to manage nerds, you need to be one. For the sake of this article, I’m assuming a worst-case scenario — you are not a nerd, but your job involves daily nerd management. My condolences, these guys and gals can eat you alive.

A good place to get mentally limber regarding nerds is with The Nerd Handbook. This is intended for the significant others of nerds and geeks and it’s a good place to start understanding the nerd mindset. However, where the Handbook explains the care and feeding of nerds in the home, this piece is concerned with nerds at work.

Multiple generations of nerds are in the workforce now, so your preconceived notions of nerdery are not as useful as you thought. Discard the nerd extremes: the curmudgeonly pocket protector set is retiring or retired and there’s a good chance that the slick brown-haired guy sitting across the bar wearing the $300 Ted Baker shirt is a fucking Python wizard.

Fortunately, a career as a nerd in software engineering still requires a well defined mental skill set, not any particular sartorial flair, and successfully acquiring and refining that skill set has tweaked the nerd’s brain in a unique way that will start to define your nerd management strategy.

Disclaimer: As with all of my articles, I use “he” as a convenience. There are plenty of female nerds out there and they display much of the same behavior.

A Problem

In front of you is The Problem. While I don’t know what The Problem is, I do know that you have a bright team of talented nerds working for you, and I know that you don’t have a clue how to tackle The Problem: you need the nerds and you don’t know where to start. The Problem is unique in that your normal leadership moves aren’t going to work. You can already predict the collective nerd reaction and it’s the opposite of what you need to happen.

Rather than attacking this Problem directly, let’s turn it around and explore the inner workings of your nerd’s mental landscape for inspired next steps.

The nerd as system thinker is a point I’ve been making since The Nerd Handbook and one I explore further in Being Geek. Briefly, a nerd is motivated to understand how a thing works — how it fits together. This drive comes from the nerd’s favorite tool, the computer, which is a blissful construction of logical knowability. Years of mastering the computer have created a strong belief in the illusory predictable calm that emerges from the chaos as you consistently follow the rules that define a system.

If I had to give you a single piece of managerial advice, I would say: “Your job with your nerd is to bring calm to their chaos”. Let’s begin.

Your nerd treasures consistency. Your staff meeting is an entertaining affair. You keep it light, you relay developing corporate shenanigans, and you crush rumors as best you can. Occasionally, you need to make a decision on the spot — random policy enforcement: Should Kate get that sweet office with the window?

You: “Sure, Kate deserves it… she’s doing great work.”

Suddenly, a normally chatty staff meeting is full of silence. What happened?

First, you nonchalantly barged your way though one of the three guaranteed topics that will cause anyone, not just nerds, to lose their goddamned minds: space, compensation, and titles. Second, your off-the-cuff decision regarding Kate is somehow inconsistent with your team. Remember, you are sitting in a room full of nerds who — just for intellectual sport — are parsing every decision you make, analyzing it, and comparing that analysis against every single decision you’ve ever made in their presence. That silence? That’s the silent nerd rage that arrives when they discover meaningful inconsistency.

The rules regarding who gets a window have never been written down, but they are known: you are either a manager who needs to have 1:1s or you’ve been with the group for multiple years and you have senior in your title. Kate has neither, and while her great work might be cause for awarding her the office, by not explicitly stating that there is an addendum to the unspoken rules regarding office windows, you are in consistency violation. You are less predictable because you are no longer following the rules of the system.

A predictable world is a comforting world to your nerd. Your inconsistency on the office ruling now has them wondering, “What the hell other random crap is coming down the line? How the hell am I supposed to get my work done when my boss engages in fits of randomness?” According to your nerd, a predictable world is a world where we know what is going to happen next. See…

Your nerd also treasures efficiency. When a nerd is mentally noting every single decision that you make, they’re not doing so because they want to catch you in a lie or an inconsistency, that’s just upside. What the nerd is doing is what they always do — sifting though impressive piles of information and discovering rules so they can discover the optimal system that governs everything. Grand Unification Theory? Yeah, a nerd invented that so he could sleep at night.

With an understanding of the rules, your nerd can choose a course of action that requires the least amount of energy. This isn’t laziness; this is the joy that in a world full of chaotic and political people with obscure agendas and erratic behavior, your nerd can conquer the chaos with logical, efficient predictability. Your nerd has a deliberate goal in mind that you need to support. Your nerd is…

Chasing the Two Highs

In The Nerd Handbook, I called this the High, but there are Two Highs:

The First High: When the nerd sees a knot, they want to unravel it. After each Christmas, someone screws up the Christmas tree lights. They remove the lights from the tree and carefully fold the lights as they lay them in the box. Mysteriously, somewhere between last year’s folding and this year’s Joy of Finding the Lights, these lights become a knotted mess.

The process of unknotting the lights is a seemingly haphazard one — you sit on the floor swearing and slowly pulling a single green cable through a mess of wires and lights and feeling like you’re making no progress — until you do. There’s a magical moment when the knot feels solved. There’s still a knot in front of you, but it’s collapsing on itself and unencumbered wire is just spilling out of it.

This mental achievement is the first nerd high. It’s the liberating moment when we suddenly understand the problem, but right behind that that solution is something greater. It’s….

The Second High: Complete knot domination. The world is full of knots and untying each has its own unique high. Your nerd spends a good portion of their day busily untying these knots, whether it’s that subtle tweak to a mail filter that allows them to parse their mail faster, or the 30 seconds they spend tweaking the font size in their favorite editor to achieve perfect readability. This constant removal of friction is satisfying, but eventually they’ll ask, “What’s with all the fucking knots?” and attack.

A switch flips when your nerd drops into this mode. They’re no longer trying to unravel the knot, they want to understand why all knots exist. They have a razor focus on a complete understanding of the system that is currently pissing them off and they use this understanding to build a completely knot-free product - this is the Second High.

Chasing the Second High is where nerds earn their salary. If the First High is the joy of understanding, the Second High is the act of creation. If you want your nerd to rock your world by building something revolutionary, you want them chasing the Second High. This is why…

You obsessively protect both your nerd’s time and space. Until you’ve experienced the solving of a seemingly impossible problem, it’s hard to understand how far a nerd will go to protect his problem solving focus and you can help. The road to either High is a mental state traditionally called the Zone. There are three things to know about the Zone:

  1. The almost-constant quest of the nerd is managing all the crap that is preventing us from entering the Zone as we search for the Highs. Meetings, casual useless fly-bys, biological nuisances, that mysterious knock-knock-knocking that comes from the ceiling tiles whenever the AC kicks in — what the nerd is doing in the first 15 minutes of getting in the Zone is building focus, and it’s a Jenga-like construction that small distractions can topple.

  2. Every single second you allow a nerd to remain in the Zone is a second where something fucking miraculous can occur.

  3. As I’ve explained before, your nerd has built himself a Cave. It might not actually look like a cave, or maybe it does. The goal around its construction is simple: protect the Zone so we can chase the Highs. Stand up right now and walk to each of your nerds’ offices and spelunk the caves. Ask the question: “How are they protecting their focus?” Back to the door? Headphones? Massive screen real estate? You don’t have to ask a single question to begin to understand what your nerd does to protect his Cave. You need to ask…

What is your nerd’s hoodie? I write better when I’m wearing a hoodie. There’s something warm and cave-like about having my head surrounded — it gives me permission to ignore the world. Over time, those around me know that interrupting hoodie-writing is a capital offense. They know when I reach to pull the hoodie over my head that I’ve successfully discarded all distractions on the Planet Earth and am currently communing with the pure essence of whatever I’m working on.

It’s irrational and it’s delicious.

Your nerd has a hoodie. It’s a visual cue to stay away as they chase their Highs and your job is both identification and enforcement. I don’t know your nerds, so I don’t know what you’ll discover, but I am confident that these hoodie-like obsessions will often make no sense to you - even if you ask. Yes, there will always Mountain Dew nearby. Of course, we will never be without square pink Post-its.

Don’t sweat it. Support it. Also, understand the interesting potentially negative by-products of all this nerdery, such as…

Not invented here syndrome. When you ask your nerd to build something significant, your nerd is predisposed to build it himself rather than borrowing from someone else. Strike that, your nerd’s default opening position when asked to build a thing is: “We can build it better than anyone else”.

First, they probably can, but it’s an expensive proposition. Second, understanding why this is their opening position is important. The ideal mental state of the nerd with regard to The Problem is the First High - a completely understood model of the problem. The issue is each nerd’s strategic approach for this high is different.

Unfortunately, code is often the only documentation of our inspiration and your nerd would rather design his own inspiration than adapt someone else’s. When a nerd says, “We can build it better,” he’s saying, “I have not devoted the necessary time to understand the existing solution and it’s more fun to build than to investigate someone else’s crap.”

If your nerd is bent on building it versus buying it, fine, ask him to prove it. Make the Problem the explanation of why building the new is a more logical and strategic approach than pulling a working solution off the shelf.

The bitter nerd. Another default opening position for the nerd is bitterness — the curmudgeon. Your triage: Why can’t he be a team player? There are chronically negative nerds out there, but in my experience with nerd management, it’s more often the case the nerd is bitter because they’ve seen this situation before four times and it’s played out exactly the same way. Each time:

Whenever management feels they’re out of touch, we all get shuttled off to an offsite where we spend two days talking too much and not acting enough.

Nerds aren’t typically bitter; they’re just well informed. Snark from nerds is a leading indicator that I’m wasting their time and when I find it, I ask questions until I understand the inefficiency so I can change it or explain it.

The disinterested or drifting nerd. Your nerd won’t engage. It’s been a week and a half and as far as you can tell, all he’s done is create and endlessly edit a to do list on his whiteboard. Whether he’s disinterested or drifting, your nerd is stuck. There are two likely situations here: he doesn’t want to engage or he can’t.

Triage here is similar to Not Invented Here — is the problem shiny? Is there something unique that will allow for the possibility of original work? Ok, it’s shiny - is it too shiny? Is your nerd outside of the comfort zone of his ability? My favorite move when a nerd appears stuck is pairing him with a credible technical peer - not a competitor, but a cohort.

Once you’ve discovered the productivity of the Highs, you’re going to attempt to invoke them. Bad news. The invocation process is entirely owned by and unique to your nerd. You can protect the cave and honor the hoodie, but your nerd will choose when to go deep. The amount of pressure you put on your nerd to engage is directly proportionate to the amount of resistance you’ll encounter.

Find a cohort. Someone who will be receptive to the perceived lack of shininess or someone who will say the one thing necessary to get your nerd chasing the Highs.

The Nerd Burden

I’ve spent a lot of time painting nerds as obsessive control freaks bent on controlling the universe. Fact is, your nerd understands how the system works. They know what you know — chaos is a guarantee. It’s neither efficient nor predictable, but it’s going to happen.

You and your nerd are surprisingly goal aligned with regard to the chaos. You want him to build a thing and you want him to build it well. You want it to perform reliably in bizarre situations that no one can predict. You want to scale when you least expect it. And you want to be amazed.

Amaze your nerd. Build calm and dark places where invoking the Zone is trivial. Perform consistently and efficiently around your nerd so they can spend their energy on what they build and not worry about that which they can’t control. Help them scale by knowing when they’re stuck or simply bored. And let them chase those Highs because then they can amaze everyone.

# January 17, 2011 : Twitter : Comments (46)
Management a distinct lack of drama

The Update, The Vent, and The Disaster

Business is noisy.

Business is full of people worrying loudly about projects, process, and other people. These people have opinions and they share them all over the place — all the time. This collective chatter is part of the daily regimen of a healthy business, but this chatter will bury the individual voice unless someone pays attention.

Your job in a 1:1 is to give the smallest voice a chance to be heard, and I start with a question: “How are you?”

The Basics

Before we start, let’s go over the basic rules I follow regarding 1:1s:

Same time each week. When you become a manager of people, an odd thing happens. You’re automatically perceived as being busier. Whether you are or not is irrelevant; folks just think you are. Consistently landing your 1:1s at the same time on the same day is a weekly reminder that you are here for them — no matter how busy.

Always do it. Ok, so you are really busy. You’re running from meeting to meeting. It’s easy to de-prioritize a 1:1 because unlike whatever meeting you’re running to or from, a 1:1 doesn’t represent an urgent problem that needs solving. I’ll beat this perceived lack of value opinion out of you later in this piece, but for now understand that each time you bail on a 1:1 they hear, “You don’t matter”.

30 minutes, at least. Another favorite move of the busy manager is to schedule a 1:1 for 15 minutes or less. It’s the best I can do, Rands. I’ve got 15 people working for me. First, those 15 people don’t work for you; you work for them. Think of it like this: if those 15 people left, just left the building tomorrow, how much work would actually get done? Second, if you’ve got 15 people working for you, you’re not their manager, you’re just the guy who grins uncomfortably as you infrequently fly by the office, ask how it’s going, and then don’t actually listen to the answer.

Having a meaningful conversation with anyone takes time. As you’ll see in a moment, you start with an opener where you figure out where everyone is mentally, which builds conversational momentum into having a conversation of consequence. In your 15-minute 1:1, all you learn is that you don’t have time to care.

How Are You?

It’s a softball opener. I recognize that, but I lead with a vanilla opener because this type of content-free question is vague enough that the recipient can’t help but put part of themselves into the answer, and it’s the answer where the 1:1 begins.

What’s the first thing they say? Do they deflect with humor? Is it the standard off-the-cuff answer? Or is it different? How is it different? What words did they choose and how quickly are they saying them? How long did they wait to answer? Did they even answer the question? Do you understand the answer isn’t the point, either? The content is merely a delivery vehicle for the mood and the mood sets your agenda.

As I’m listening to the answer I’m discerning your mood and I’m throwing you into one of three buckets regarding the type of 1:1 we’re about to have:

  1. The Update (All clear!)
  2. The Vent (Something’s up…)
  3. The Disaster (Oh dear…)

The reads on the majority of the 1:1s fall into the first bucket. The answer to my softball opener is pleasant and familiar. We’re going to walk through the facts, dig a little bit here and there, wander, and then it’ll be over. Great. The other two buckets are trickier to assess with a single question. Your answer to my question is… off. You either state this up front with the alarming, “We need to talk” proclamation, which immediately throws you in the Vent bucket, but this could also easily be a Disaster. By far, the worst answer to the opener is the quiet one, the answer that contains something hidden and insidious.

Oh dear.

The Update

You get exactly what you expect from The Update — it’s status. These are my projects and these are my people and this is how it’s going down. I believe most folks consider this type of 1:1 to be a success and they’re wrong.

A 1:1 is not a project meeting. A 1:1 is not status report. See all those project managers scurrying to and fro? Their job is the maintenance of the facts and the discovery of project truth. If you’re drawing the line for success in your 1:1 as the discussion of data you could find in a status report, you’re missing the point. A 1:1 is an opportunity to learn something new amidst the grind of daily business.

When a 1:1 starts and is clearly an Update, I start listening twice as hard for a nugget of something that we can discuss, investigate, and explore. It’s not that I don’t care about status, it’s just that we’ve got 45 minutes here and if we fill that time with data I can find scrubbing the bug database and the wiki, we’re both wasting our time.

So, I listen, I take it on myself to find a meaty conversation, and if I don’t find it in the first 15 minutes, I’ve got three moves:

Move #1 - Three Prepared Points: While I believe part of a good organic 1:1 is improvisation, I usually have three talking points in my back pocket that have shown up over the past week regarding you or your team. If we can’t find a good thread of conversation in the first 10-15 minutes, I’ll start with one of these points and see where that takes us.

Move #2 - The Mini-Performance Review: You read that right. If we’re 15 minutes into a lifeless, redundant, status-based 1:1 and I don’t have anything sitting in my back pocket, I’m going to turn this into a performance review. It won’t be your actual performance review; it’s one aspect of your review that somehow strikes me as more appropriate conversation than an update on your bug counts. I see you’ve got a handle on your bugs, but one thing we talked about at your last annual performance review was getting a better handle on the architecture. How’s that going?

Move #3 - My Current Disaster. Chances are, in my professional life, something is currently off the rails. It’s selfish, but if you’re leading with status and I can’t find an interesting discussion nugget, let’s talk about my current disaster. Do you know how many open reqs we have that we can’t hire against? Who is the best hiring manager you know and what were their best moves? The point of this discussion is not to solve my Disaster, the point is that we’re going to have a conversation where one of us is going to learn something more than just project status.

Business is noisy because there is always stuff to do and the process of doing stuff is called tactics. It’s tactical work and while tactics are progress, the real progress is made when we get strategic. A productive 1:1 is one where we talk strategically about how we do stuff, but, more importantly, how we might do this stuff better.

The Vent

A really good Vent starts with a disarmingly long period of silence. I’ve just asked my soft opener and you’re quiet. Really quiet. I can see you mentally gathering steam. I take this time to ground myself because while I know a Vent is coming, I likely don’t know the content or the severity. Vents vary from a semi-tense “I can’t stand QA today” to a full-on explosion: “If I have to listen to Thomas grind his goddamned Fair Trade Certified Peruvian coffee beans in his office ONE MORE TIME, I might lose it.”

When the Vent begins, you might confuse this for a conversation. It’s not. It’s a Vent. It’s a mental release valve and your job is to listen for as long as it takes. Don’t problem solve. Don’t redirect. Don’t comfort. Yet. Your employee is doing mental house cleaning and interrupting this cleaning is missing the point. They don’t want a solution, they want to be heard.

A Vent does have a conclusion. There is a point where you need to jump in, but these conclusions and your actions vary.

#1 It’s Done. The Vent starts to lose steam and the Venter finds themselves panting and staring at you with nothing to say because they’ve said it all — probably a couple of times. It’s in this moment that you begin your triage. Great, now we start talking…

#2 It’s a Rant. A Vent can repeat itself. The same facts and content might be thrown at you in a couple of different ways. I see this repetition as healthy way of chewing on the problem, but there’s a point where this Vent becomes a Rant. After a couple of Vent cycles, you might try grabbing hold of the conversation and starting with triage, but brace yourself — they might not be done — and my suggestion, in the face of resistance, is to give them the benefit of the doubt and let ‘em go another round.

The Vent that wants no help is a Rant. The Ranter somehow believes that the endless restatement of their opinion is the solution. Perhaps they have no clue what a solution might be or how to find it or perhaps they’ve been stewing on the topic so long, they’ve lost all sight of logic.

Whatever the back story, the Ranter is finding some weird mental satisfaction in the endless restatement of the problem, but they have no interest in solving the actual problem at this point. Annoying. When you’ve got a confirmed Rant on your hands, it’s ok to jump into the middle of the Vent — you’re saving everyone a pile of time and you’re teaching the Ranter that the incessant restatement of the Rant is not progress.

#3 It’s a Disaster. You’re listening carefully to the Vent. It’s moving forward and it’s not repeating itself, but… something is up. Perhaps it’s their demeanor or maybe it’s the topic, but your radar is pinging. The Venter is not standing on their usual soapbox. They’re out of character and, as time is passing, they are becoming less themselves.

At its core, the Vent is motivated by emotion. That’s the key difference between the Update and the Vent. The topic has triggered an emotional response and their therapy is the verbal statement and restatement of the situation. Emotion is a slippery slope, and what can start as a Vent has a chance of spiraling into a Disaster. It’s rare in business, but it’s a risk when you’re dealing with emotionally slippery human beings.

The Disaster

If a Vent feels like a speech, a Disaster feels like an attack. What started as an emotional conversation has transformed into a war, and you’re suddenly and unexpectedly on the battlefield.

Until you’ve seen the Disaster once, it’s hard to predict how you’re going to react to the perception of being attacked. For better or worse, it’s happened enough to me that when I see the Disaster approaching, I carefully tuck all of my emotions in a box, lock the aforementioned box, and magically transform into a Vulcan.

When the Disaster arrives, the absolute worst response is any semblance of emotion. See, they want to fight. They literally want to go a couple of rounds on this particular topic. What was a high degree of frustration has transformed into pure aggression and if you so much as blink improperly, you’re contributing to the escalation of this situation.

Some tips:

Like the Vent, success is traversing the emotional explosion. There will, hopefully, be a point when the majority of the emotion has passed and they’re willing to having a rational discussion. Unlike the Vent, the discussion is not about the core issue. It starts with the Disaster, with understanding the intense emotion surrounding the topic.

A Disaster is end result of poor management. Your employee believes totally losing their shit is a productive strategy - they believe it’s the only option left to making anything change.

Assume They Have Something to Teach You

The cliché is “People are your most valuable resource”. I would argue they are your only resource. Computers, desks, building, data centers… Whatever. All of those other tools only support your one and only resource: your people.

People mentally wander. It’s in their nature to make off-the-cuff observations — “Why does Phil get the choice features?” — and to let those observations fester, mutate, and sometimes transform into a Disaster. I’m not suggesting that every 1:1 is a tortuous affair to discover deeply hidden emergent disasters, but you do want to create a weekly place where dissatisfaction might quietly appear. A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team. A 1:1 is a place to listen for what they aren’t saying.

The sound that surrounds successful regimen of 1:1s is silence. All of the listening, questioning, and discussion that happens during a 1:1 is managerial preventative maintenance. You’ll see when interest in a project begins to wane and take action before it becomes job dissatisfaction. You’ll hear about tension between two employees and moderate a discussion before it becomes a yelling match in a meeting. Your reward for a culture of healthy 1:1s is a distinct lack of drama.

# September 22, 2010 : Twitter : Comments (33)
Management Rules so people know when to talk

How to Run a Meeting

I bag on meetings.

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

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

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

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

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

“No one is code reviewing his stuff…”

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

“And he just checked into your component.”

“He what the fuck what? STAN!”

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

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

Alignment versus Creative

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A good referee knows:

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

A Culture of Meetings

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

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

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

# August 19, 2010 : Twitter : Comments (12)
Management A more predictable place

Pick-Up

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

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

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

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

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

This was organically understood until Campbell showed up.

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

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

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

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

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

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

Uncomfortably Different

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

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

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

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

A Defensible Rule

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

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

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

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

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

Values, Not Rules

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

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

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

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

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

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

They Didn’t Know

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

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

# June 8, 2010 : Twitter : Comments (6)
Management Amorphous moments of clarity

The Twinge

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

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

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

Shit.

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

She had a Twinge.

Twinge Acquisition

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

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

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

I don’t.

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

How to Build a Twinge

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

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

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

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

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

A Day of Stories

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

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

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

A Familiar Nail

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

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

“Is the design done?”

“Yes, except for items six and seven.”

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

“In a week and half.”

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

“I, uh…”

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

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

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

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

A Twinge Catastrophe

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

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

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

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

Your failure to heed your Twinge is a management failure.

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

Just Another Nail

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

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

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

# April 26, 2010 : Twitter : Comments (17)
Management Your instantaneous first reaction

Knee Jerks

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

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

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

One Eighth of a Second

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

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

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

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

The Jerks

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

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

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

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

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

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

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

No.

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

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

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

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

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

It’s not.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stages of Jerk

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

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

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

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

# February 18, 2010 : Twitter : Comments (13)
Management Hire for your career

Wanted

Jesse walked.

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

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

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

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

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

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

Jesse walked.

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

I had not explained to Jesse that he was wanted.

The Requisition Situation

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

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

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

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

This leads to the most important rule regarding requisitions:

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

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

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

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

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

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

Spend an hour a day on each req you have

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

An hour?

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

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

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

Here’s how to start:

But isn’t this why I have a recruiter?

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

I found them! I’m done!

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

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

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

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

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

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

Deliberate Want

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

Her: “Why not hire Alex?”

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

“Have you asked?”

“No.”

“I’ll ask.”

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

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

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

We continually and consistently explained that they were wanted.

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

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

It’s exhausting.

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

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

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

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

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

Hire for Your Career

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

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

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

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

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

# January 4, 2010 : Twitter : Comments (26)
Management Because they want to win

Gaming the System

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

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

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

Like I said, grim.

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

I needed a game.

An Entertaining System

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

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

Discovery — From confusion to control

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But there is one last phase to consider, achievement.

Achievement — Who cares if you win by yourself?

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

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

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

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

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

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

The Rules of the Game

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

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

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

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

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

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

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

The Whiteboard Game

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

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

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

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

“Points for what?”

“Points for points. We’re geeks.”

“And everyone has their own color?”

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

“Blue?”

“Yeah, I’m always blue.”

# December 13, 2009 : Twitter : Comments (45)
Management What you need to do next

No Surprises

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

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

I wish.

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

And then there’s the surprise.

Show Me the Money

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

I didn’t think so.

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

Let’s fix that.

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

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

Measures versus Content

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

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

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

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

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

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

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

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

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

Tell me which is more useful:

“You did well.”

-or-

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

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

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

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

A Review is a Conversation

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

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

Calm yourself.

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

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

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

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

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

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

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

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

Surprise!

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

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

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

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

The Permanence of the Written

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

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

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

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

So I did.

# August 31, 2009 : Twitter : Comments (16)
Management Real change is hard

A Toxic Paradox

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

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

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

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

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

These people are toxic.

Big Fat Toxic Assumptions

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

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

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

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

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

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

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

Go Team!

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

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

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

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

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

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

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

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

Yes, this is a worst case scenario.

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

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

Reasonable. Professional. Respectful.

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

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

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

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

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

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

A Toxic Paradox

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

No.

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

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

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

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

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

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

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

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

No? Maybe?

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

# June 21, 2009 : Twitter : Comments (40)
Management A deliberate moment of consideration

A Deep Breath

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

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

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

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

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

Sigh

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

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

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

You can let that breath out now.

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

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

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

  1. In the absence of direction, people make shit up. Nature abhors a vacuum and in the absence of solid information, people generate their own information to fill that vacuum. They’re not lying, they have no ill will, they’re just trying to build a semblance of structure amongst the confusion. This is only exacerbated by the fact that…

  2. Human beings provide mutual group therapy by endlessly talking about the crisis at hand. This isn’t the creation of new content; it’s just the regurgitation of the latest new. At the right time, this hallway cross-pollination is a great way to evolve an idea, but if all we’re doing is talking about the crisis, all we’re doing is scratching at the worry rather than dealing with it.

  3. Lastly, everyone wants to know everything. Combine the communication vacuums and the group therapy creating a fire hose of additional questionable content and it’s not surprising that everyone on the team wants to know everything. Before I proceed, I want total disclosure. I have something unique to add and I better get a chance to do so.

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

Three Meetings

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

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

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

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

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

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

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

Operations — Where are we?

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

Tactics — What are we going to do about that?

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

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

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

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

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

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

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

Invest in the Boring

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

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

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

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

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

# June 1, 2009 : Twitter : Comments (27)
Management Trust So You Can Scale

A Disclosure

My management career began with a misunderstanding.

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

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

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

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

Me: “Wait, I can do that?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See, your world has expanded, now…

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

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

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

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

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

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

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

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

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

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

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

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

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

“No.”

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

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

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

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

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

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

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

Trust So You Can Scale

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

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

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

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

# January 25, 2009 : Twitter : Comments (32)
Management Are we done?

The Larry Test

Larry was pissing me off.

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

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

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

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

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

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

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

Done

This is an article about choosing to be done.

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

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

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

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

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

Are You Larry Worthy?

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

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

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

Before You Land the Larry

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

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

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

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

No, he’s not.

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

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

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

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

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

An Evolving Done

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

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

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

This is my test and I need to pass it.

# January 18, 2009 : Twitter : Comments (22)
Management Random moments of high potential

The Trickle List

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

Here are three tasks from my current list:

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

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

No.

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

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

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

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

Trickle Header

Trickle Creation

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

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

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

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

Here’s my current list:

“Rands, these are simply recurring tasks.”

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

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

Wait, the project is HOW FAR behind?

Hold it, you’re thinking about QUITTING?

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

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

Trickle List

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

The Trickle Process

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

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

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

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

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

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

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

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

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

Structured Improvisation

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

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

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

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

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

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

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

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

# August 18, 2008 : Twitter : Comments (13)
Management The art of choosing what not to do

The Taste of the Day

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

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

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

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

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

Delicious, delicious structure. Sweet, sweet definition.

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

The New Gig

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

Today’s record for consecutive uninterrupted seconds is 47.

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

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

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

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

The Taste of the Day

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

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

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

The Morning Scrub

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

Three Different Tastes

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

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

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

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

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

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

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

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

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

Practice Productivity Minimalism

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

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

The Evening

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

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

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

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

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

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

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

“Rands, I can do anything!”

Of course you can.

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

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

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

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

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

And that one is called the Trickle List.

# July 22, 2008 : Twitter : Comments (35)
Management A one-trick rant pony

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.

# September 25, 2007 : Twitter : Comments (19)
Management Why are we here?

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.

# August 31, 2007 : Twitter : Comments (41)
Management An odd metallic taste

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.

# June 20, 2007 : Twitter : Comments (2)
Management WE'RE BUDS

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.

# December 10, 2006 : Twitter : Comments (8)
Management Blue Whale for President '08

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.

polar bear“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:

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.

# November 22, 2006 : Twitter : Comments (9)
Management Pardon me, what?

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.

# November 17, 2006 : Twitter : Comments (12)
Management Osmosis Hallway Guy

Secret Titles

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

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:

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”.

# July 25, 2006 : Twitter : Comments (8)
Management They might be evil

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?

eager young manager by spider

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.

# June 13, 2006 : Twitter : Comments (9)
Management Incessantly demonstrating your hunger

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.

# June 12, 2006 : Twitter : Comments (0)
Management How much action per decision?

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.”

pep talk by spider

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.

# June 9, 2006 : Twitter : Comments (1)
Management Transforming glaring deficiencies

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.

# June 8, 2006 : Twitter : Comments (1)
Management Give him something to say

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.

# June 7, 2006 : Twitter : Comments (4)
Management There is evil

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.

the big squeeze

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.

# June 6, 2006 : Twitter : Comments (5)
Management Take a deep breath

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.

# February 17, 2006 : Twitter : Comments (44)
Management Underwear work days

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.

# February 10, 2006 : Twitter : Comments (10)
Management A policy beating

Remotely

Anyone who’s worked with me has stumbled on my policy on remote employees. The short answer is, “No”. The longer answer is, “The team is moving far too fast for you to miss the various hallway conversations which randomly point us in different directions.”

Software is art. It’s team art. When the team collectively decides to start painting blue over a round of stiff drinks, you, as a remote employee, are going to look pretty silly come Monday when you’re still painting red. It’s this communication latency that troubles me. I’d rather freely communicate rather than worry about whether or not I’m freely communicating or not.

My remote employee policy has been taking a beating for years. First, we, as a software development community, continue to spread out. It’s entropy at work and it’s being driven by insane home prices as well as ever improving means of high bandwidth communication with folks on the other side of the planet. Combine those facts with my impression that the population of qualified developers outside of the US is exploding and I’ve got a policy problem.

Ok.

I’ll adjust.

In fact, I have to as an employee recently made a run for the Northwest and there was no other option than to let him work remotely.

I’m ready to learn and that’s today’s question, “How do you, as a remote employee, stay in the loop?” The converse, if you prefer, is, “How do you, as a co-worker or manager of a remote employee, keep everyone on the same page?”

So far, I’m trying the following:

What else works? Other tips? How are you making remote work?

# January 27, 2006 : Twitter : Comments (35)
Management In silence, you can assess

Subtlety, Subterfuge, and Silence

Managers, wanna-be managers, and folks who want to understand managers simply need to read the 48 Laws of Power by Robert Green and Joost Elffers.

I’ve purposely not done any background research on this document because my first reaction to this list was profound and I wanted to stare at that reaction. There’s some pretty evil shit documented there as well as some basic truths about what managers are up do on a daily basis. I can’t tell if the guys who wrote this are serious when they write “Keep Others in Suspended Terror: Cultivate an Air of Unpredictability”, but after several readings, yeah, I think they’re serious.

My problem with this list and how it relates to managers is that some many of the “rules” involve psychological torture of those you’re trying to lead and that strikes me as a good way further the intense knee-jerk reaction regarding managers. “That guy is a power hungry jerk’.

Still…

Part of management is navigating your way through some tricky political jungles… Part of management is getting folks to comfortably bend in a uncomfortable direction. A good manager is a person who is playing to a strategy and isn’t merely stumbling around squashing fires all day.

Management is chess. When you’re presented with a problem, you sometimes need to sit back and take a look at the board, figure out the consequences of each of move, and, most importantly, pick a move. In my experience the move and how you pick it does not involve 48 laws, it’s only three words. Subtlety, Subterfuge, and Silence.

Subtlety

Worst performance review ever. I’ve just delivered a painful performance review to a fictional employee and he doesn’t get it. Two weeks I spent writing this thing, gathering peer feedback, and rewriting and he’s sitting there like everything’s dandy. I’m not about to fire this guy, but given his current trajectory, he’s two years from becoming irrelevant and I want to nip this in the bud, but it’s radio silence.

“Any questions?”

“Nope.”

“Are you clear about the areas I want to work with you on?”

“Yup.”

Now, the point of a performance review has nothing to do with the review, it’s the discussion. It’s about constructively conveying information about the performance of the co-worker and then chewing on it a bit. You want to see some form of processing of the information you just dumped even if it’s just a pile of follow-up questions.

I was getting nothing.

So I moved on. It was our 1:1 and I had a list. We started with the first item which, last week, read “Thoughts on moving forward on Project X.” This week it read, “Lack of progress on Project X, next steps, and goals.” The second item had read, “Hiring status” and this week it read, “Weekly goals for resume review, alternative sourcing strategies.” Yes, I’d rewritten my entire 1:1 with the performance review in mind.

The employee in question wasn’t comfortable with the strategic broad-strokes I’d painted in his review, but he certain got it when I carefully reconstructed his 1:1 to support the review. By the end of the 1:1, I’d piled his to-do list so high, we were actually back talking about the performance review because it was that advice that was going to help him get the work done.

To me, using subtlety as a manager is the ability to elegantly handle complex situations. This elegance, this ability to cleverly handle the complex, only happens when you have time to consider your response. That’s the other half of subtlety. It’s the ability to look at what’s happening around you and make a make a distinction between useless noise and emerging relevance.

Subterfuge

Say it with me, “sub-ter-fyooooooooj”. We should make shirts, it’s that fun to say, but what does it mean? Subterfuge means “intrigue, deviousness, deceit, deception, dishonesty, cheating, duplicity, guile, cunning, craftiness, chicanery, pretense, fraud, fraudulence”. Those definitions cover a lot of territory, so let’s refine it for the sake of this piece.

Relative to management, this does not mean “deceit, dishonest, cheating, fraud, or fraudulence”… it’s everything else. I’ll explain.

We were at a crossroads at the start-up. Too much to do, two vastly different directions in which the team wanted to head. There were the infrastructure folks who wanted to spend three months replacing the application server and then there were the interaction folks who wanted to improve the usability of the application. The VP listened to both sides and then he decided, “Infrastructure! Long term scalability!”

The interaction folks were pissed. Their response, “Who cares about long term scalability if no one wants to use the product?” Oh yeah, I was also the manager of the interaction folks and I agreed with them, but I had to throw my engineers on the infrastructure work because we didn’t have the capacity. I was talking with existing customers and they weren’t pulling their hair out because the application was sluggish, but rather because it was an interaction nightmare. They were spending most of their time trying to figure the damned thing out.

Grrrrrrrrr.

The lead interaction designer, myself, and an engineer sat in a conference room fuming in silence when it popped in my head. “Hey, people are visual creatures, how long to throw together a prototype that shows off what we were thinking?”

My engineer, “A week!” Good time to point out how enthusiasm reduces all engineering estimates by a third. My engineer continued, “But I’ll need Frank.”

Hmmmmm.

“Here’s what we’re going to do. I want you and Frank to work on this after 5pm, after we’re done with our infrastructure work, and I want you to keep this on the downlow. If, after a week, we like what we see, we’re going public.”

Herein lies the hard part of subterfuge. Depending on where you are standing, my plan could be viewed in any number of ways. The other engineering director would have called it, “Disobeying a direct order” whereas my boss, who got wind of the effort two days in, called it “a skunk works project” and told us to proceed. Phew.

Our skunk works took us three weeks, not one, but when we showed off our work, the VP of Engineering and VP of Marketing were impressed and wanted to see us finish the work. Rather than sacrificing the infrastructure effort, they gave me two reqs so I could hire a team to do the job right.

Subterfuge is a risk. The infrastructure director never quite trusted me after that even though I still went out of my way to keep him in the loop after we went public with our work.

The use of subterfuge for good means keeping the intent honest. If you’re going commando to do what you believe is right, it doesn’t means someone isn’t going to be pissed, but it should allow you to sleep at night.

Silence

Your most annoying employee sits across the table and he’s on a roll. This guy is total and complete personality clash with you and he’s in his second hour of rambling about something you don’t understand. My advice is simple:

Shut up.

I mean it.

Now, if you know what he’s trying to get at and you’ve continued to let him blither, ok, you can start talking and directing him elsewhere, but if he’s valiantly trying to get to the point, you must shut up and listen. Your silence is giving him a chance to get something out.

I’m not a fan of public speaking. I’m not comfortable with the all hands meeting where I’m laying out the next six months of work. My natural state is one of introspection where I’m soaking in the world and the skill has taken me far because so many folks out there just can’t shut up. While all this talking is going on, I sit quietly and nod… learning what all these yammering people are about and carefully file it away for future reference.

Managers lead and a lot of managers translate that into “managers lead by talking”. Combined with the tendency of employees to not say no to these managers, you can see why a lot of us have turned into professional windbags. We think we’re guiding you by filing the air with our thoughts. There’s a time and place for that, but in order to fill the air with something relevant, you’ve got to gather and process data.

In silence, you can assess.

My favorite use of silence is a huge cross-functional meeting with a group I’ve never worked with before where I have no role other than listener. It’s a table full of people I don’t know and I feel like I’m sitting at the worst poker table ever because everyone tells you what they got.

Remember this, in most business, everyone’s basic agenda is visible after they’ve talked for about ten minutes. I’m not talking about who they are as a person, I’m talking about figuring out what they have and what the need. In poker, you keep this information hidden as best you can because your money is on the line. In business, everyone throws their hand on the table, stands up, points at their hand, and says, “People, I’m one card away from the nut flush. Who’s going to give the queen of hearts?”

Asking for what you need is a good strategy in business, it’s called collaborating. Each time I hear “I need”, I learn another bit about those I work with and, in time, I can construct a better picture of how to interact with my co-workers.. Still, I’m also wondering about that guy in the corner who isn’t saying a thing. His eyes are darting around the room just like mine and I’m curious… what is he getting out of his silence?

Business isn’t War

The 48 Laws of Power are the real deal, but they are focused on war, not business. There’s a book if you want to know more, but read wisely. With each successful year on the job, I find myself adjusting to the ever increasing complexity with which my peers play the game of management. Fifteen years in, I can safely say there is one law which is true; if you’re only interested in building power, you’re going to lose.

# January 23, 2006 : Twitter : Comments (4)
Management The art involved is sometimes subtle

Ode to a Chain Saw

Everyone at work chuckles when I, once again, tell them I was out with the chain saw this weekend. They’re laughing because they’re trying to picture their nerd boss act like a mountain man. Fact of the matter is, I am a nerd. I do call Verizon every month or so to see when they’ll be lowering my DSL price and increasing the speed. I like futzing with my Tivo and I can program in C++. I also love my chain saw. Deal with it.

I have fond memories of the smell of a chain saw. My Dad has been using them for forty years, so I grew up with the stench of burning gas and fresh cut wood. Still, The Dad was bright enough to keep me away from the chain saw until I was ready. I’m the guy who killed an orchard with a Volvo when I was eighteen… we called it “vehicular orchardcide”. So, probably not a good idea to let me near lethal weapons until I turned twenty. He waited until I was thirty.

The previous home owner left me a chain saw, so I’ve been busy. Fire wood, you see. Oh yeah, kindling, too. What’s that? Need those bushes trimmed? Be right there. Waitwaitwait, let me clean-up that Christmas tree for you. I HAVE JUST THE THING.

Since this piece is really going no where, I leave you with this — it’s a list of how your many skills as a manager are like a chain saw.

# December 6, 2005 : Twitter : Comments (8)
Tech Life There are no pixies

Saying No

Somewhere in your third year of being a manager, the Management Pixies will appear in your office in a puff of sweet smelling black smoke. There will be three of them and one will be carrying a gorgeous black top hat.

“Are you LeRoy McManager?”

“I am.”

The Pixies laugh. “Congratulations, you have passed successful through three years of management and we’re here to reward you, but first, one question: Have you seen Spiderman?”

“The first one or the sequel?”

“The first one.”

“I have.”

The Pixies laugh again. “What do you think the primary theme is in Spiderman, LeRoy McManager?”

“Um, hmmmm… life’s a bitch?”

Strangely, the Pixies don’t laugh. “No, try again. It’s important.”

“Ok, well. Hmmmm… Peter’s Uncle said something they kept yammering about… OH I KNOW… With great power comes great responsibility.”

The Pixies cheer and the one carrying the top hat flutters over to you and drops it in your lap. It’s soft and strangely warm. The hat-bearing Pixie looks up at you and grins, “You wear this hat when you want people to know who you are.”

“And who am I?” You look down at the hat and notice massive white block letters on the front, they read:

I’M THE BOSS.

A slow grin stretches across your face and you realize the hat has the vague smell of your Mom’s fresh baked bread. That smell has always given you a strange sense of confidence and you know that whenever you wear that hat, you’ll been infused with that sense of confidence.

All three Pixies leap into the air giggling, “Good luck LeRoy McManager, use your hat well!” More laughing. Another puff of black smoke and they’re gone.

You lift the hat slowly in front of your face, staring at the white block letters, soaking in the sense of power the hat gives you, and you put it on.

You stride out of your office never once wondering why the Pixies were giggling so much because, well, you’re the boss. The first person sees you walk by in your cloud of confidence and, once you walk around the corner, you don’t hear them snicker because, again, you’re the boss.

They’re laughing because while they know you’re the boss, they can see the other side of the hat and it reads.

… FOR NOW.

Managers can lose it.

I mean it. There are managers out there who are absolutely punch drunk with power and if you’re working for one of these folks, I’m really sorry. You’re a resident of Crazy Town and that means you never know what random crap is going to happen next and that sucks.

Manager’s don’t start crazy. It’s an acquired trait and this article explores what I consider the single best tact you can take to avoid a trip to Crazy Town. Let’s tackle it first with a story from an employee’s perspective.

You’re merrily typing way at your keyboard, hard at work at the next great feature when your boss walks in and says, “Hey, can you work on a Gizzy Flibbet?”

“Uh, isn’t the Flubjam the key feature? I’ve barely even started it. It’s going to take awhile”

“Oh yes yes, we’re still doing Flubjam, but I need you to prototype the Gizzy Flibbet and I need it in two days for a meeting with the Execs.”

“Oooooooook, you’re the boss.”

“That’s right, I am the boss.”

Two days pass and you pour your soul into the prototype feature. Like all investigations, you discover each step of discovery takes three times as long as expected. The final prototype coveys the idea, but the process to create that result has left you drained and pretty sure finishing the remaining work is going to take a really long time.

When your boss walks into your office, you summarize, “Here it is. It looks good, it’ll take awhile and I’m now very behind on my Flubjam work. Can I please get back to it?”

Squinting her eyes, she runs her fingertips along the front rim of her top hat. She nods and stares, “Ok, THIS IS GREAT. Let’s do this AND Flubjam AND let’s hit the same schedule! Go us!” She turns and leaves the room leaving your office with the faint smell of bread.

I’ll recap. Your boss has just picked the one scenario that involves the most work and has the least chance of succeeding. You’re screwed and while you might think your boss has lost it, you are a co-conspirator in this disaster because you didn’t do one simple thing, you didn’t Say No.

Losing It

Manager don’t lose it simply because the Pixies showed up with the top hat, they lose it because those they work with forget to look at the back of of the hat. Remember:

Management is myth… just like the top hat. We, as employees, believe it’s there, so we treat these management types different. Yes, they sign the checks and they write the reviews, but, in a perfect world, those events are a function of your performance and not theirs, so it’s your job to not screw that up. I realize that’s a big fat stretch, but stick with me.

What is the real source of a manager’s perceived power? It’s the idea that they can make decisions. When the the team is stuck on a problem, they gather up in the manager’s office, present their case, and the manager nods and says, “Go that way!” More often than not, everyone is so happy to be past the logjam, they don’t even question whether it’s the right decision or not. “He’s got the top hat, so he must be right!”

No no no no. Also. No.

Managers lose it when they are no longer questioned in their decisions. When the team stops questioning authority, the manager slowly starts to believe that their decisions are always good and while it feels great to be right all the time, it’s statistically impossible. The most experienced managers in the world make horribly bad decisions all the time, the good ones have learned how to recover from their decisions with dignity, but, more importantly, help from the team.

Let’s take a look at Saying No from the manager’s perspective without any Pixies.

Back at the start-up, we were considering the move to a hosted model for our web application. I, in my third year of management, was in charge of presenting the pros and cons of such a move to the Executive Staff. We were in the middle of three huge deployments, so I decided to not put the necessary work into the presentation. I wrote it the night before and didn’t vet it with anyone. The end result asked more questions than it answered. It was a mess.

The Executive Staff went pretty easy on me. It was clear from their questions that they weren’t happy with my half-baked ideas and I left the room thinking I’d blown it.

The first person I saw after the meeting was Doug, one of my managers. Doug, “Rands, way to go! You hit it out of the park, man! When do we get started?” In my state of depression, Doug’s enthusiasm for my crappy presentation was intoxicating. Maybe I was being too hard on myself? Maybe it was a good presentation and I’m just being too sensitive? Yeah, that’s the ticket.

The second person I found was Randy, my other manager. His comment, “Ouch. That stung. What’s our recovery plan?”

Sure, I wanted to punch Randy, but he was spot on. I’d blown it and any other conclusion was a load of crap. The irony in all of this is that Doug believed he was doing the right thing by supporting me, but he was only eroding his credibility with me by not telling it straight. Think of it like this, if I’d swallowed the Doug Happy Pill, I would’ve done nothing to recover from my failed presentation and I would have looked like an idiot to the Execs.

What I did do was swallow the Bitter Randy Pill and completely redo the presentation along with the help of my managers. We presented a week later and actually did hit it out of the park. That’s with the truth gets you… progress.

No Versus The Truth

Randy didn’t Say No, he told me the truth, but I’m leaving this article entitled “Saying No” because I think it’s harder to contradict your boss than to tell the truth. Saying No forces an idea to defend itself with facts. Sure, no one really wants to hear their idea is crap. It’s hard to Say No and it’s even harder to Hear No, but who do you want to work with? People who are going to help you refine your direction or ones who will merrily follow your downward spin to Crazy Town?

As with every job, your success as a manager is the end result of innumerable decisions. While the front of your top hat reminds everyone that you’re the one making the decisions, the back of the hat reminds everyone else that, more importantly, you’re the one responsible for those decisions.

For Now

# November 21, 2005 : Twitter : Comments (12)
Tech Life Pick your kool-aid

Management Cheat Sheet

There’s an article somewhere in my head which dissects the intense knee jerk reaction a lot folks have regarding managers. The question is, “Why do so many of us automatically assume that our managers are boobs?” The follow-on question is, “Even if we don’t think our managers are not boobs, why do we constantly ridicule them behind their backs?”

Clearly, the answer is rooted in our basic issue with authority. “Who does HE think HE is? More important than ME?” No, he’s just got a different job than you. Yeah, he’s probably got more to affect change now, but that he didn’t a few years back. He was you. So, what are YOU going to do about it?

The article needs to be written soon because my role continues to wander about the organizational chart and at each part of the chart, they serve a different kool-aid. This drink tastes great, but it slowly dulls my memory. It makes it harder to context switch to where I was versus where I am. Could be age, too.

To preserve these thoughts, I present you the Management Cheat Sheet. It leads off with a generic version of the Rands Communication Template and finishes with neatly organized lists of the various articles hiding on this site.

As you read the articles, you’ll notice I jump around a bit in terms of audience… sometimes I’m focused on the manager and sometimes on the employee. Here’s the point: There is no difference. Just because your boss can fire you doesn’t mean you can’t quit.

Rands Communication Template

People appreciate consistency… especially in business. They want to know what occurred today is likely to occur tomorrow.

“RANDS? HELLO? What about Messy Thinking? Signs of Art? Taking Time to Think? HOW DO I INNOVATE WITH CHAINS OF CONSISTENCY?!?!?”

Calm down.

Ever hung with a hardcore successful artist? Painter? Writer? I bet their workspace was a total disaster. I bet you wondered, “How is the world does this person produce their art in this mess?” They don’t produce, they create. There’s some studio or publisher out there who does the production and they need consistency because they’re responsible for the cash and the cash vanishes, the gig is up. Our artist can still create in this scenario, but can they eat?

The Rands Communication Template is document designed to allow you to consistently communicate with someone else. Maybe it’s your boss or maybe it’s your team. It doesn’t matter. What matters is that in your regular communication meetings, you are talking about the same stuff in the same way.

This template is a work in progress, but here’s the skinny:

My process with this document is simple. I update my template the morning of my meeting. To do this, I look at last week’s version for an interesting or hot issues I noted in the prior meeting. Ideally, I’ve already moved on these and have something to report.

During the meeting, I follow the order on the carefully folded sheet. People, Program, and Product. Success can be measured in two ways: healthy conversation during the meeting or awestruck silence. Your mileage may vary.

With feedback from y’all, I’ll be happy to continually update this document. I would absolutely love to hear from folks who have tried to use this document. I would absolutely love to see real world versions of this that folks have tried with the managers and employees.

Rands Communication Template v.02 (PDF)

Ok, useful articles:

Understanding the Team

These articles focus on figuring out who the hell your working with and for. I have a tendency to map personalities on a spectrum where they are either THIS or THAT. In reality, there are multiple spectrums and the following articles describe a bunch of them:

Understanding the Company

Ever wondered why there are useless meetings? Confused by your new company’s lingo? Not clear why your boss is yelling at you? The following might help:

Improving the Team/Yourself

Constant improvement only comes from constant challenge. How you communicate and deal with that challenge will define you as an employee, a manager, or a soon-to-be-unemployeed loud mouth:

Creativity in Development

It’s relevant that the last section is the most fun. Figuring out how to build stunning products is job #1. I can help:

# October 6, 2005 : Twitter : Comments (6)
Tech Life More than the sum of it's parts

Signs of Art

There’s a never ending battle going on in your software development team right now. It’s the battle between the Organic Engineers and the Mechanical Engineers and it sounds like this:

Organics: “Software is art!”
Mechanics: “Software is logic! It’s fact! And it’s a lot of work.”
Organics: “You’re right! It’s work but it’s artful work.”
Mechanics: “When you call it art, you trivialize our work. I design lightweight database libraries and it took my team of four engineers 18 months to roll out last version and it’s compliant with RFC 2354 and blah blah words acronym words blah blah.”

It’s at this point the Organic glazes over and starts dreaming about how they’ll design a stunning application on top of this whizbang database.

As I’ve said before, we need both Organics and Mechanics (as well as Incrementalists and Completionists) to get our bits out the door, but what I really want to say is…

Software is art.

The follow-up to this statement is “What is art?” Brighter folks than I have spent their careers working on this question and I’d like to apologize in advance to each one of them. I’m just some schmoe sitting on the floor of an airport waiting for my flight, but I’m going to take a stab at definition.

Art is “the documentation of a thousand interesting decisions”.

Let’s take that apart word by word:

“The documentation…” In order to qualify as art, you’ve got to be able to share it with others. This means capturing it on some canvas whether it’s paper, a DVD, a web page, a city, or your skin. If you can’t share your art, it’s not art. It’s a conversation with yourself and I’m sure you’re fascinating, but why not share it with the rest of us?

“… a thousand…” A thousand is a swag. It describes that there needs to be some perception of effort for a work to be art. I’m specially YELLING AT YOU MODERN ART because YOU OFTEN FAIL THIS TEST. A matchbox poorly glued to a large piece of purple construction paper is not art. Sorry.

I’m not suggesting that an outside observer needs to look at art and say, “Gee, that looks hard to do. I couldn’t do that.” The observer needs to experience something in the piece whether whether it’s the size, weight, or complexity of the work and can’t be created with a single trivial decision.

“…interesting decisions…” Now, here’s the heart. Art is is when someone captures a set of decisions worth remembering. Blue or red? Serif or sans serif? Ruby or Python? San Francisco or New York? Up or down? As I said above, one decision does not art make (STILL GLARING AT YOU MODERN ART), it’s the collection of all the decisions… captured… that create a conveys a unique idea to the observer. It’s not just whether they can see/hear/feel this idea, it’s whether they find inspiration in their aggregate perception of these decisions. It’s a personal thing. Some decisions will inspire, some will bore and the sum of all the decisions will affect each person differently.

Software is art.

It’s a thousand decisions captured in code and displayed as user interface, services, and any number of other useful and artful conveniences. I would further argue that a great piece of software has equal ability to change the world as any great piece of art and if you disagree, I direct you to exhibit A, B, and C.

Believe it or not, that’s just introduction to this piece. What I really want to talk about is my secret Software as Art checklist. This is my personal list of discrete events I watch for in a team which engaged in the practice of building artful software.

This list will annoy every program management lovin’ mechanic out there. I swear I tried to shake as many of them off with the whole fuzzy (yet relevant) art introduction. If they’re still here, I need to say that I’m not suggesting that the following is a means of gauging a project, it’s a means of taking the temperature of a process which is creating art. I will further frustrate everyone reading by merely giving you a means of measuring without suggesting how to improve your team environment. That’s another column or two.

Measuring Team Art

Teams which are building art display the following traits:

1) High tension at inflection points. Traditionally, folks start yelling whenever you move from one development phase to the next. Sometimes there are formal meetings around these transitions, sometimes not, but what I’m looking for in the yelling is a team that is choosing to challenge the process.

If you’re moving from design to development, folks should be asking questions like, “Do we have the right features?”, “Has anyone bothered to write specifications?”, or “I don’t understand the vision for this product.”

If you’re moving from developing to deployment, the questions are different, but similar in tone, “Have we fixed enough bugs?”, “Do these features work?”, “How’s our Beta going?”, or “Does anyone else but me think this is crap?”

The key to this tension is not that folks are tense, it’s demonstrating that they are engaged. They know these development inflection points are critical public decision points and if they’re taking the time to care then they’ve got skin the game. Art is never created by those who are following the process.

2) Ideas appearing out of no where. Love this. You’re wandering the hallways on a Saturday afternoon and two engineers are idly talking about Feature X. It’s a casual conversation, so you plant yourself against a wall and listen in and WHAM HOLY SHIT she just totally redefined Feature X with an off-the-cuff comment. SOMEONE WRITE THAT DOWN.

As I mentioned in the Taking Time To Think piece, great ideas only come when you’re soaking in a problem. Hallway brilliance only comes when the team is breathing the product.

3) Efficient Decisions. Another good sign that folks are busily creating art is they are making their own decisions. This might be hard for a manager to swallow because you’re getting paid to lead, but, trust me, you want the folks staring at the code to know two things:

When you combine “efficient decisions” with “ideas out of no where”, you’re really cooking. A lot of folks freak out when they see a brand new feature in the product two weeks before the feature complete milestone. Yeah, it’s called feature creep and it’s hard to ship a moving target, but it’s worse to ship bits that are uninspired.

4) Evening and weekends. The traditional senior level productivity measurement is, “Is the team working weekends?” Senior execs believe a team really needs to “burn it at both ends” to ship a product. Furthermore, they believe that providing food for said weekend week is an incentive. Here’s your wake up call folks:

No one ever worked a weekend for free tacos.

When it comes to weekend and late night work, the question is not “Are they?” the question is “Will they?” Success here is a simple measure. Does the team go the extra mile without being asked? You see this behavior in start-ups all the time because the team knows who the team is. “It’s me and these three other guys and if we don’t do it, no one else will.” In larger companies, this perception is diluted because there is so many frickin’ people. It becomes, “Well, someone is going to fix this, right? Right?”

Measuring Despair

At every entrance to the Silicon Valley there’s this huge road sign. It reads:

Welcome!

You’ll notice that the sign says nothing about art. That’s right. You can do better, faster, and more and make scads of money without a smidge of art. Is that company you want to create? To work for? Really? Bummer. You can stop reading now.

If you’re still here, you know that the combination of a desire to build art and the BetterFasterMore mantra will invariably lead a development team to believe it’s screwed. No matter how inspired, creative, or innovative the group can be, they will arrive at an psychological impasse where all will appear lost. This is where you, the manager of people, will realize a couple of things. First, even though you’re no longer contributing code, the decisions you make regarding moving the team past despair is your essential contribution to the art that is your software. Second, you are responsible for the flavor of despair the team is experiencing.

One flavor of despair tastes like that last sip of coffee that’s been sitting in that paper cup all day. Cold, useless, and full of coffee grinds. It’s got a hint of promise, but it’s mostly an empty reminder of what was…. it’s depressing. The other flavor of despair is metallic in taste… it’s the flavor that floods your mouth when you’re being chased by a bear. It’s scary, but the adrenaline is kicking in and that means SHIT WE’LL JUST RUN FASTER.

There is a flood of management terms which change the taste of despair. Empowerment! Collaboration! Thinking outside the box! These words pasted on big fat pieces of paper and slapped all over the building do exactly one thing: they clutter up the joint. Changing the taste of despair and building a team that wants to create art is a full time gig and I’ll spend a lot of time writing here about how to do it. Sorry to leave you hanging, but I’ll leave you with a simple observation.

If you’ve got a team full of bright artful people, they’re going to have endless opinions about what is art and what is not. They will argue, they will yell, and there will be times when you hate the person you respect most because you are incapable of admitting they are right. This roller-coaster of pain and pleasure always ends at the same spot. It stops when all of the team’s hard-work is judged by one person — the customer. A finicky, opinionated person who will make the most important decision — is it art?

# September 30, 2005 : Twitter : Comments (11)
Management Why can't you think when you're busy?

Taking Time to Think

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

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

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

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

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

REACT versus THINK

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

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

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

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

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

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

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

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

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

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

GETTING STARTED

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

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

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

PLAYERS

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

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

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

CONTENT

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

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

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

IS IT WORKING?

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

Good work. Really.

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

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

WHEN TO STOP

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

FIGHT STAGNATION

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

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

# August 30, 2005 : Twitter : Comments (7)
Management A management style that scales

Don't Be A Prick

With the completion of the Fez column, I have enough content to start stitching together a book based off my various management essays. Book publishing has never been a stated goal, but based on the response to many of the articles, there’s a good chance folks outside the webosphere might find my management musings of interest.

Problem. What’s the pitch? BE A GOOD MANAGER? ZzzzzzzzZ. There are hints of themes amongst the various management articles, but there is no single article which sets the stage for the rest… that hints at a basic truth that ties my reposing together.

There is now…

Flashback to the middle of the dotcom implosion. We, the merry crew of the failing start-up, are drinking… a lot. There are various bars around corporate… each have a distinct purpose. There’s the dive bar that’s great for post-layoff parties. The booze is cheap and if you’re looking to blow off some I’m_Really_Not_Worthless steam, you can pick a fight with the toothless sailor slung over the bar or the guy who just laid you off.

Down the street is the English pub. The beer is better, they have a selection of whiskey, and they have edible food. This is where we get philosophical about the current organizational seizure we’re experiencing in our three year slide towards irrelevancy.

We’re there now. We’re drinking heavily because the company has just been sold to a no-name public company who will quickly dismantle the company we’ve bled for. Everyone knew we’d be here at some point, but no one expected to be the last one standing. And no one expected the CEO to show up.

This isn’t the CEO that built the company. He’s been gone for over a year. This is the guy the Board of Directors brought in to sell the start-up. Sure, he tried to turn us around, but, remember, we’re in the middle of a financial nuclear winter here. Money is no longer free.

Those who got a glimpse of the CEO’s resume before he arrived knew the gig was up. His last four jobs ended in the company being finely sliced into into nothingness. It’s called “maximizing shareholder value”.

And here we are. Hammered on tequila… the last four from engineering. Two guys from tech support… and the CEO. Even though we’re dizzy with booze, we’re fundamentally uncomfortable with the presence of our CEO because we consider him to be an unfeeling prick.

And that’s it.

That’s the title of my management book.

“Don’t be a prick.”

Right so, the editors are probably going to have an issue with the word “prick” in the title. It falsely implies a masculinity to management which is a crock, so we’ll call it a working title until the actual editors show up.

The CEO in question is not a prick. Good guy. Straight talker. Good financial sense. Many failing companies did a lot worse that ours, but that isn’t the point. The reason we sat there drunk and uncomfortable was because we had absolutely no connection with this guy. He was the mechanical CEO.

My definition of a great manager is someone that you can make a connection with no matter where you sit in the organization chart. What exactly I mean by connection varies wildly by who you are and want you want and, yes, that means great managers have to work terribly hard to see the subtle differences in each of the people work for them.

See. See the people that work with you. They say repetition improves long term memory, so let’s say it once more. You must see the people that work with you.

If you don’t have an inkling of what I’m talking about yet, it might be a good time to set this (potential) book down and head over to programming section of the book store because it’s time to reconsider that pure engineering career tract. Being a manager is a great job (I mean it), but it’s your ability to construct a insightful opinion about a person in seconds that will help make you a phenomenal manager. Yes, in a technical management role…, you need both the left and right sides of the brain, but just because you write great code doesn’t mean you’re going to have a clue about how to lay off 70% of your staff.

Every single person you work with has a vastly different set of needs. Fulfilling these needs is one way to make them content and productive. It is your full time job to listen to these people and carefully mentally document how they are built. This is your most important job. I know the Sr. VP of Engineering is telling you that hitting the date for the Project is Job #1, but you are not going to write the code, test the product, or document the features. The team is… and your job is the team.

I know the Silicon Valley is full of wildly successful dictators. These are the leaders who are successful even though they are world class pricks. This book is going to push you as far from prickdom as possible and if that means I’m decreasing the chance you end up on the front page of the Wall Street journal labeled a “corporate bulldog with vision”, well, I’ve done my job.

You get to choose the type of manager you will be and if you want to work with your team, if you want to learn from them, if you want them to trust you, well, I’ve got some advice for you. Lots of it. Keep reading.

Again, the CEO at the start-up was not a prick. He just showed up at the wake for the company and assumed that we’d be comfortable with his presence because HE WAS THE CEO. We knew he was CEO. More importantly, we knew he’d spent exactly zero time using our products. We’d never seen him there on the weekend. Come to think of it, he was never there on Friday either because he commuted from another state. We had no shared experience with him other than three strange meaningless all hands meetings filled with slide projectors, spreadsheets and monotony.

The CEO believed that these spreadsheet-laden all hands meetings were all the connection he needed to build and, for the duration of that meeting, he was right. We felt well informed after his meeting, but our needs were different a week later when rumors of layoffs started up. They were drastically different a month later when that layoff went down and the CEO was nowhere to be seen.

Organizations of people are constantly shifting around. They are incredibly messy. In this mess, judgments of you and your work will be constructed in moments… in the ten second conversations you have in the hallway… in the way you choose to describe who you are.

Meanwhile, you need to constantly assess those you work with, determine what they need, figure out what motivates them. You need to remember that what worked one day as a motivational technique will backfire in two months because human beings are confusing, erratic, and emotional. In order to manage human beings in the moment, you’ve got to be one.

And that’s why a better title for my book is:

“Managing Humans”.

# May 18, 2005 : Twitter : Comments (6)
Management Someone is going to yell again

Big Bad Conflict

Some time during your tenure as a manager the sky is going to fall. I’m not talking about a schedule slip or a spirited meeting or being screwed. I’m talking a total disaster… yelling… fighting. Best case, HR is involved. Worst case, so are lawyers. This is conflict of a magnitude you’ll only see a few times in your life… and you’re in the middle of it. Sorry about that.

Bad news first. I can’t help prepare you for this particular disaster because it’s of a unfamiliar make and model. Every team, product, and company is different which means your particular disaster requires insider knowledge which I don’t possess. My brief advice is always… if the shit is hitting the fan… call HR. They can help. They can fortify.

What I want to talk about is how your worst break-up ever prepares you nicely for this disaster.

Rough segue, I know, but bear with me.

First, we need to set the wayback machine for that time your were dumped by the love of your life. You know, the one where after the deer was done, you were barely recognizable to your self. It’s the one you swore you were going to climb into your car and drive to the other side of the planet because life was over as you knew it. Sure, you didn’t actually do it, BUT YOU SURE MEANT IT.

I’d like to propose a moment of collective weblog silence for all break-ups like this because, wow, they suck.








Ok.

We get over these break-ups not because time passes it’s because whoever dumped us usually comes back… several times. I mean it, as long as there is no restraining order involved, the person who dumped you calls you back and you both do something which you both think is stupid, but is actually quite healthy. You hook-up again in some fashion. Then, one of your quickly realizes why you broke-up in the first place and the break-up occurs again… and again.

This happens so reliably in my relationships that, later in my life, break-ups became slightly less painful because I knew that while she was dumping me that she’d have to call in the next two months because, at some point, she’d just remember more good stuff than bad stuff and wonder why we broke up.

boingCall ‘em relationship bounces because I think the whole break-up process looks like a bouncing ball. The moment you break-up you drop a big red ball on a flat surface… metaphorically. Time passes, the ball hits the ground with a decent amount of force and proceeds to reach another peak which is never as high as the original. This peak represents a relationship bounce where you plus your significant other briefly relieve your relationship. Repeat as many times as necessary which each peak representing an ever small bounce of the relationship which eventually fades.

Now, we’ve all sat in a bar with our friends telling us how stupid is to hook-up with your ex, but I’m here to tell you it’s a brilliant idea. Each bounce is a chance to heal because the last person you should be talking to about being dumped is your friends… they’re telling you what you want to hear. You should be talking to the dumper because they have the most information… and they convienently always come back.

Relationship bounces help you heal.

You are now officially wondering how in the world I am going to tie this back into the corporation. Here it is: Major conflict follows the same pattern as a bad break-up… it’s never over after the first event. It echos… it rebounds… and, as a manager, you need to be aware of this pattern for a couple of reasons.

First, you need to understand that whatever your conflict is… it’s going to coming back. You’re going to be seriously relieved when the first storm passes, but you need to immediately prepare for and possibly induce the next bounce because it’s coming… someone is going to yell again… someone is stewing in their office right now and your job is be ready for the next conflict.

Second, each bounce should be progressively smaller because you know it’s coming and are doing something to prepare for it. The worst case scenario is when the original conflict occurs and the second bounce is as bad or worse… we call that escalation and escalation is a sure sign someone is asleep at the wheel.

Third, and lastly, just like a bad break-up, these rebounds are essential. Sure, there will be more yelling, but when someone is yelling, they are working on something… they are, hopefully, making mental progress on whatever it is they are trying to communicate. When I found myself staring at the middle of a big bad conflict, my first thought is, “How am I going to make the next bounce happen faster?” You read that right. I want bounce number two because that brings me even close to bounce number three. See where I’m headed? Subsequent smaller conflict bounces means we’re making progress and are ever closer to resolution.

The number one thing to remember about big bad conflict is that, just like horrible break-ups, people are about as emotional as you’ll ever see them. Conflict is not the time to make decisions, make judgments, or really do anything except try as hard as possible to calmly weather the storm. You’re human so you’re going to be tempted to jump into the emotional fray, but that’s not your job.

Your job is mediation, you are neutral, and each passing moment of conflict is making you a stronger manager.

# February 26, 2005 : Twitter : Comments (0)
Management Figuring out how your manager acquires information

Organics and Mechanics

Stop. Grab a pencil and write down the first and last names of your past three managers. Stare at those names for a bit and re-live those months or years of reporting to this person. I want your off-the-cuff opinion about each one.

My guess is your opinion falls into one the three buckets:

I love this guy. Best manager ever. I still talk to him on a monthly basis because this guy taught me everything I know about what I do. He is my mentor.

Mostly harmless. This guy doesn’t really challenge me, but then again, he’s not really slowing me down. I’m not learning much, but I don’t have to put up with much bullshit. Also, I’m not sure what he actually does, but he leaves me alone… so… whatever.

Worst. Manager. Ever. This guy makes my life a living hell. I dread our weekly 1:1. I prepare for an hour and we still end up talking about random useless crap. It’s like we’re speaking a different language. I don’t know what he wants and, even if I did, I wouldn’t want to give it to him because I’m so annoyed. I mostly want to give him a poke in the nose.

I want to talk about Worst Manager Ever because, chances are, you’re right… you are speaking a different language and he’s just as frustrated as you.

As an individual contributor or a manager, you interact with two populations — those you work with and those you work for. The conversations with these two populations are distinct. With co-workers, you speak the Truth. You speak it because each of you are slogging out in your respective trenches, so what good is there to say anything but the Truth?

With managers, you speak the Way. The Way are the things we shall do to achieve organizational enlightenment. “Verily, I shall scribe a specification and it will be a good thing” or “Yea, it came to pass, I say unto you, I am working weekends.” The Way is however you’re communicating up to your manager. It’s different content and it’s different tone and if you believe you have the Worst Manager Ever then you’re not doing it right.

In order to understand how to speak to your manager, you’ve gotta figure out how they acquire information and, chances are, they either gather it Organically or Mechanically.

Your first job is to figure out whether you’re working with an Organic or a Mechanic. To do that, think of any problem as a very complex itch. Now, this is no normal itch, it’s a complex itch and scratching said itch is going to take some work. Here’s the inner dialog for a Mechanic and then an Organic regarding how their going begin their scratching

Mechanic: “An itch. Well. This itch seems familiar. In fact, I scratched this type of itch in January 2001. Let me first dig up my notes regarding that itching. Excellent. We’re going to need an matrix. The vertical column will be action items I can think of that will assess different scratching scenarios and the vertical axis will measure our progress against these different scenarios. Ok, we’re going to need a meeting to form a committee… “

Organic: “Wow, an itch. Hmmmm… well, this sucks. Hey Frank, we’ve got a itch… whaddya think? Yeah, that’s what I was thinking. You know, this itch seems familiar… I think I’m going to deeply consider this itch while I drive home, but, first, where’s Mary? She knows all about itches and I bet she’ll have some ideas… I wonder what happens when I type itch in Google… HEY… there’s an idea…”

Mechanics move forward methodically. They carefully gather information in a structured manner and store that information in a manner that makes easiest to find again. They quietly observe, they stay on message, they are comfortably predictable, and they annoy the hell out of Organics.

Organics are all over the place. They tend to be loud and they can tell a joke. They ask seemingly meaningless questions. They lean forward when they talk to you. When confronted with a horrible situation, you’re going to think they’re insane because they appear to be still smiling.

A large part of the managerial conflict can be summed up in the following scenario:

An Organic and a Mechanic are staring at each other across the desk and are thinking the following:

Mechanic: “This guy is walking chaos”.

Organic: “This guy is totally uptight.”

They are both right because they both violate each others sense of propriety. Knowing this solves half the problem. The other half is figuring out how the hell to communicate and that’s the hard part.

Prior gig, four years ago. I was hired in by the CEO as a Director while they continued to search for a VP of Engineering. As an aside, let me stress how bad of a career move it is to NOT know who you are going to be working for when you arrive. The thirty minute interview you have with your future manager is a critical piece of information when you decide whether or not to make a move. Here’s why.

The VP of Engineer showed up a few months later and he seemed like a bright guy. Good technical background… a bit quiet for my taste, but I’m loud so we’ll balance out, right? Our first 1:1 showed up, so I grabbed my big black notebook and plopped down in his office and WHAM HOLY MICROMANAGEMENT.

“What’s going on with this? How is Person X? What about Person Y? Have we done XYZ task? No, why? Why again? No really, why?” Question question question data data my lord does this guy think I’m sitting around surfing the web? Ok, deep breath Rands, it’s his first week and he’s gathering information so I’m going to cut him slack. He’ll chill out once he realizes I’ve got things under control.

Nope.

One month later and the barrage of questions is non-stop. This guy peppers me with random questions and I consistently leave his office feeling like I’ve been doing nothing WITH MY 72 HOUR WORK WEEK. It’s a cop-out to label this guy a micro-manager. Great, he’s a micro-manager. So what? I’m still going to walk out of his office on a weekly basis thinking I’m useless. He’s clearly Mechanical, but so what?

Remember, Mechanical managers gather information in structured way. They do this because they aren’t great at relating at people, so they let the left brain take over as a means of content acquisition. This means that if you have a Mechanic for a manager, you need to push the information in a structured, well known, and consistent manner.

For my prior manager, I wrote a status template. It started with products and listed current relevant bits for each of the products on my team. Following that, I listed personnel issues team by team. Contractor status, requisition status, vacations.

Each week, I’d fill this template out 24 hours before my 1:1. This was my first pass which loaded my brain with this week’s content. I’d remember things we’d talked about the week before and make sure that I’d have the most recent data on those hot issues. An hour before the the 1:1, I’d review again and fine tune. When the 1:1 arrived, I pulled out my print-out and started. I stayed on message and I never deviated from the template. Every week. The same structure chocked full of dates, data, milestones… anything concrete and real.

Consistency. Structure. He loved it. I literally jumped up and down after the 1:1 where he didn’t ask a single question because I predicted every single possible question he might ask.

My VP was a Mechanic and he wanted to feel the structure that encompassed dealing with every problem. Guess what, I’m a Organic. My 1:1s start with a “Hey, how the hell are you?” and then they wander. You’re going to walk out of my office thinking we just shot the breeze for a bit, but as we chit-chatted, I was carefully gathering content. What was your reaction to question X? What questions did you ask me? Yes, I appear to be collecting trivial crap with my random questions, but I tend to gather more information than Mechanics because who the hell knows what I’m going to ask.

That’s one situation. There are more and I guarantee yours is unique. My advice:

If you work for an Organic…

You’ve got to trust that they’ve got a plan even though it may not be immediately apparent. Don’t confuse an extremely open mind with cluelessness. Organics often have a more complete picture about what is going down because they are better networked.

If you’re a Mechanic, you’re going to feel a bit lost with your Organic manager because you’re OK with lightweight forms of micromanagement. It gives you structure. Most Organic managers I’ve worked with can put on a Mechanic hat and provide that structure, but you’ve gotta ask because it’s not their natural state.

It’s true. Organics often miss detail as they hurry from place to place.

If you work for a Mechanic…

Like I said above, a Mechanic will not believe you’re dealing with something until they feel the structure that encompasses a problem your solving. You must overload your Mechanic with data in order to satiate their structured brain. If your Mechanic keeps asking you the EXACT SAME QUESTION and none of your responses appear to be the answer, it’s time to counter with, “I really don’t know what you are asking.”

If you’re an Organic, you will wrongly assume that Mechanics don’t trust you.. and you’re right… they don’t. You will build trust by acting like a Mechanic with them. It takes practice, but since you’re already working for one, you’ve got a great role model. I’m not suggesting you need to transform yourself into a Mechanic (which is impossible), you just need to speak Mechanic long enough to sooth your Mechanical manager. Once he’s figured out you’ve got chops, you can start going Organic on him. He’ll deal.

Look out for…

Like Incrementalists and Completionists, the most dangerous Organic/Mechanic type is the switch hitter. My personal favorites are Mechanical Organics. These folks have all the slick tricks of Organic information gathering, but they’ve got the astounding organization skills of the Mechanic. They know everything and never forget a bit. I mean it.

Organic Mechanics are frightening. They have extreme depth of knowledge, but there is no obvious organic thread which ties it all together. Here’s the scary part. There is a thread. There is a purpose. They just aren’t letting you see it. Organic Mechanics will keep you on your heels and just when you think you’ve figured them out, they’ll change everything. I hate that.

The answer is in the middle

Organics doing battle with Mechanics or vice verse… is a waste of time. Organizational warfare does one thing… focus on the people rather than the business and that means you’re losing cash money. Whether it’s my manager or my co-worker, when I find myself in a Organic/Mechanic conflict, I think this:

“A purely Mechanical organization lacks inspiration. A purely Organic organization is total chaos.”

Organics fill Mechanical blind spots with their intuition and their passion while Mechanics create a healthy, solid home where nutty Organics can run into things at speed. It’s a team thing.

# February 20, 2005 : Twitter : Comments (13)
Management How to Lose Your Job, Pt. 2

Avoiding the Fez

Ed: This article assumes you’ve read Part #1.

The first article finished with the big Rands revelation that it’s the manager’s job to figure out how to give Fez a swift kick in the butt. Yes, Fez needs to have the brains to listen and react to constructive advice, but that’s his deal. If I’ve done everything I possibly can to illuminate a path of growth to an employee and they’ve chosen to hang out in the dark, well, ciao Fez… unemployment is a terrific motivator.

Let’s start with the bad news. There’s no silver bullet to solve the Fez issue. Solving Fez is going to involve strategy, effort, inspiration, luck, and, lastly, a bit of time. You won’t solve it in a moment and you won’t solve it in a meeting.

There is a convenient yearly inflection point where everyone panics about their careers. Annual reviews. I’m going to construct this article around annual reviews, but I don’t want you to think that performing an annual review will solve the Fez. If you worry about career development once a year, you’re screwed. As you’ll see below, avoiding the Fez is a full time job, but since you get actual allocated time to stress about employee development why not stress in a constructive manner?

A BRIEF SIDEBAR ABOUT ANNUAL REVIEWS

People do care about cash. When that annual review begins, your employee is hanging on every word… carefully listening to your tone wondering, good review or bad review? If it’s sounding good.. that must mean cash; and cash rocks. If it’s sounding bad, they stop listening and start pre-bittering themselves for hating you for the next month since you clearly have NO IDEA where they ADDED THEIR VALUE this year.

Compensation adjustments are the result everyone cares about, but does anyone actually know how they’re calculated? What happened over the previous 365 days to result in a BIG CASH WINDFALL or an INSIGNIFICANT PITTANCE?

If you don’t draw a concrete line between a coherent understanding of an employee’s performance and their reward/punishment, you are only adding more fuel to the argument that “Managers sit around doing nothing all day”.

Let’s begin…

FIRST, GATHER YOUR THOUGHTS, BUT DON’T THINK (YET)

Here’s the deal. If I asked you right this second to tell me about your particular local Fez, you’ve already got a strong opinion, but it’s an opinion of the moment. It’s the latest three interactions you’ve had with your Fez and while those are relevant, they hardly represent a complete picture of the past year.

When you’re assessing an employee, you need to assess against their job, not the work they’ve done over the past two months. This is hard because this is the Silicon Valley and no one knows what happened two months ago… GOOGLE IPO THEN IPOD PHOTO THEN CHRISTMAS, RIGHT? DID I MISS ANYTHING IMPORTANT? IS TIGER OUT YET?

You did. Every month, your team produced something and it’s your job to document that production. I do this by spending an hour a month jotting down reflections of the team for the past 30 days. What stands out in my mind… What’d we do? Who rocked? Don’t get hung up on documenting every single event or talking about every single person… just type. Even if you miss massive contributions by a team member, the act of capturing your thoughts at the time they were happening creates a handy mental bookmark. This bookmark captures not only what you wrote, but everything else hiding around it so that when you go back and read the last summer’s terribly small entry:

“This month blew. No time to write.”

You’ll not only remember that y’all were on a death march, but you’ll also remember that Eddie the QA guy was there with you that weekend and, oh hey, he’s been here every single weekend and, wow, why aren’t we promoting him?

Regular snapshots of your team’s work will construct an impression of your team that you are incapable of constructing in the moment because, in the moment, you’re cranky about not getting coffee this morning, stressed about your product review next week, and DON’T GET ME STARTED ABOUT THE 300 MAILS I HAVE YET TO READ. How can you create an objective opinion of someone’s performance with all this crap in your head? You gotta step back, take a deep breath, and reflect.

As you sit there staring at the ceiling chewing on a year of thoughts, an overall impression is going to form… you can’t avoid it, but I’m asking you to ignore it for now. I’m going to distract you by proposing a model that you could use to look at your employees and begin to understand what exactly are their career needs. The model is Skill versus Will.

SKILL VERSUS WILL PLUS EPIPHANIES

It’s a simple graph. One axis is skill — how much skill does the employee have to do their job? Are the qualified? Over qualified? How long have their been doing it? When is the last time you know they learned something new? How quickly do they handle tasks compared to their peers?

The other axis is will — this is where we measure the employee’s desire. Do they like their job? Really? Have they told you that? Are they viewed as energetic by their team? When is the last time they generated a great idea that blew your mind? Are they talking in meetings or listening? Are they EVER talking? Are they ALWAYS talking?

This graph is not a precision instrument. It’s a tool to better define the impression you’re constructing of your employee. Once you’ve placed someone on the Skill/Will graph, you can begin to consider what your full time job is… constantly and consistently pushing your employees to the upper right quadrant… high skill (I’M GOOD AT WHAT I DO) and high will (I LIKE WHAT I DO). This mental map is your first step in constructing a Fez avoidance insurance policy.

“Rands, um, what exactly am I pushing constantly and consistently?”

Great question.

Worst case scenario. You’ve ignored everything I’ve said so far. You’re spending fifteen rereading your Fez’s review from last year… spending another fifteen throwing together this year’s review by cutting and pasting the one and only review you wrote for all your employees… making it unique by inserting their full name and project name. Dear Lord. You’ve really blown it.

Yet, you haven’t fully blown it. A complete fuck up is when you take this pathetic excuse for a review and present it. You say, “Employee 629, here is your review. You did this well, you did this poorly. Here’s your 4% increase and here’s your indecipherable objectives for next year. BACK TO WORK.”

You deserve every single Fez that you get. Please stop reading and move to a Red State. Thank you very much.

If you’ve taken some time to reflect on the full year… if you’ve mapped your employee against Skill and Will, you’ve probably had some epiphany regarding the Fez. You’ve realized, “Wow, they’re bored” or “She really has no clue how to architect software”. Great, an epiphany… it’s a start, but it’s not a finish. You are not the one who needs to have the epiphany — it’s your employee who needs it.

I’ll explain via the real fictional Fez. Go back and think about where you’d put him on the Skill/Will graph.. Your gut might say, well, he’s worked a lot of years, so he’s high skill and he’s just bored, so he’s low will

Nice try, but you don’t have the 12 months of fictional notes that I have. See, Fez’s skill used to be high, but it’s fading… it’s middle of the road skill now and the slow reduction is also affecting his confidence… his will. His diminishing skill is diminishing his will which, in turn, further diminishes his skill because he has zero confidence to go gather new skills. Yikes. A Skill/Will negative feedback loop. Didn’t see that coming, did you?

Here’s the upside. Just as Skill/Will fade together, they also rise together. If you focus on one, you often fix the other. It’s a brilliant management two-for-one.

Back to Fez. Let’s say your epiphany is to get Fez some technical training… send him to a C++ class and WHAM he’s going to be happy. HURRY, write that down as an objective because WOW you’ve really nailed that Fez problem.

Easy Eager Manager. Slow down.

ANOTHER BRIEF SIDEBAR — ASSERTIVENESS

I’ve got a a task for you and I’m going to ask you in two different ways. You tell me which request you’re going to actually do:

Request #1: You — go fix that bug.

Request #2: Hey, can you look into bug #1837?

The difference between these two requests is a management style which shows up in every personality test. You, Mr. Manager, are either ASK assertive meaning that you ASK in order to get stuff done or TELL assertive which means you TELL to make progress.

There are a great many charismatic leaders who’ve made billions by only telling folks what to do… I am not one of them. It’s not that I’m conflict adverse or that there are not times that I’m an incessant dictator, it’s merely I hate being told what to do, so I treat others like I’d prefer to be treated.

Telling your Fez what the problem is without belief on their part that a problem exists is tantamount to a personal attack. “You, Fez, are doing a poor job and I’ve decided that objectives x, y, and z are the only way that we’re going to save your job.”

I exaggerate for example, but I’ve had ten plus years of reviews and I’ve had some phenomenal managers turn a review into a speech about me… without involving me… and, well, I happen to be expert about me, so can I please be involved in the discussion?

An annual review is a discussion, not a speech. The goal of the discussion is to, first, agree that the review is in the ballpark. Remember, you’ve been thinking about the review for weeks because you’ve got a deadline… Fez is seeing it for the first time and he needs time to mentally digest. It’s very hard to be mentally nimble when you’re manager is staring you down asking, “Any questions?” It’s doubly hard when they’ve just told you you screwed up for the past year.

Rule of thumb. If you’re delivering big bad news, schedule TWO meetings. At the first meeting, you’re presenting the review… not the objectives. They’re going to want to know about compensation and you’re going to want to say it, but don’t. The moment you say “No increase”, the review is over, the employee is pissed and you’re going to be on the defensive. The meeting has become a mental fight and fights only prove who can punch harder.

It’s the second meeting where everyone involved has had time to digest the review. You can have a discussion about objectives because Fez drove home the prior night wondering, “My manager is telling me that I’m getting stale and I vehemently disagree with that… buuuuuuuut maybe there’s some truth in what he’s saying… Hmmmmmmm.”

With just a smidgen of agreement that the review is fair combined with you and your Fez agreeing about his place on Skill/Will, you can start talking objectives. What can do we to increase skill or will? New job? New tasks? Training? Maybe move him off that team of pessimists so they can spread their wings with some optimists?

Maybe get them out that the job of nay sayers so they can spread their wings with some optimists?

I don’t know what is up with your particular Fez, so I can’t advise specific objectives, but here are some high level thoughts about the extremes on the Skill/Will graph:

BIG FINISH

Fez is career drift.

You’ve got some Fez in you right now. You may be the rockstar of your company right now, but you have no clue that three guys in a garage in San Jose are spending every waking hour working to make you irrelevant… they call it the New Whizbang and you’re going to hate the New Whizbang when it shows up because you know it replaces your corporate relevancy.

Your manager is not going to hate the New Whizbang because she doesn’t feel personally threatened by it. She is going to see you Fezzing out about it and, hopefully, she can figure out to trickle objectivity into your indignation.

I have a simple way of managing against Fez. I tell everyone I hire the same thing, “I hired you because you’ve got enough skill and enough will to have my job one day… whether you want it or not.” This statement tells those I work with that I expect them to succeed and reminds me to keep moving because there is nothing like having bright people nipping at your heels to keep you running.

# January 24, 2005 : Twitter : Comments (7)
Management I'm the guy who's telling you the way it is

Mandate Dissection

In your quiver of management skills, you’ve got a couple of powerful arrows. There’s the annual review where you take the time to really explain, in detail, what a given employee needs to do to grow. That’s huge. That can be life changing. That’s a big arrow. How about the layoff? That’s when you get asked who stays and who goes. You’re going to lose some sleep when you’ve got to pull the bow back on that one.

A dog in a bagThen there’s the mandate. The mandate is when you gather the team together and calmly say, “This is the way it is.” No Q&A. No collaboration. It’s your dictate handed down from on high.

Most folks have learned to despise the mandate.

Rewind a few years back. I’m at my prior gig and we’ve just hired a new VP who, well, I really liked. This guy was sharp, experienced, had a litany of name brand companies on his resume, and he could tell a joke. Sold. Hired.

He was pretty quiet the first few weeks… checking out the landscape… sitting in on various meetings and listening. Engineering was in the process of discussing some drastic new directions for our products and the incrementalists (ship it soon!) were doing battle with the completionists (ship it when it’s done!). Tensions were high. Finger pointing, yelling… all the things you aren’t supposed to do in business.. but yet THEY FEEL SO GOOD when you KNOW YOU’RE RIGHT.

The VP’s second month arrived and we were still yelling. In my Wednesday 1:1 with the VP, he simply told me, “We are going to do it like this. End of discussion.”

Right so, of course I started spewing, “See, we still had to resolve issue #27 and, boy, were the completionists going to be pissed.. and had you thought about risk #12A? Blah blah blah…” He let me go for awhile and then he repeated himself, “We are going to do it like this. End of discussion.”

I might have nodded, I don’t remember.

As predicted, the team freaked. One completionist assured us he was going to quit. He slammed his door. The incrementalists weren’t happy either because they’d didn’t like being told what to do… they like to run the show. We had a good solid week of organizational disarray and… then we got back to work.

The new VP employed the mandate. He said, “I’m the guy who’s telling you the way it is”.

Now remember, I liked this guy, but, in the back of my mind when someone gives me an order, I don’t hear the order, I hear “Shut up, get moving, I don’t care what you think”. Your job as a manager is avoid giving this impression at all costs because it eventually erodes your credibility. I’ll tell you how.

There are three distinct phases to the mandate: Decide, Deliver, and Deliver (Again). Since you are the ultimate decision maker regarding this particular matter, we’re going to call this a Home Grown Mandate. These are opposite of external mandates which we’ll talk about later. Let’s begin.

Decide

Your first step is to decide when to employ the mandate and to also understand what the consequences are of laying down the law. There are thousands of little tiny decision you and your team make during the course of a day. A majority of these decisions come and go and no one is the wiser. Every so often, a big decision comes along. Doesn’t matter what the content is, what matters is that some portion of your team is on one side of the decision and other group is on the other side… and they’re arguing.

Collaboration, cross-pollination, debating, arguing… whatever you want to call the process… well, it doesn’t always work. Sometimes the team is so polarized that they start confusing the emotion with the decision. Rather than arguing the facts, they begin to argue from their heart and that is when you need to consider the mandate. Rule of thumb: When the debate is no longer productive, it’s time to make a decision.

My management style is to allow the team to argue as long as possible. I’ve got a collaborative management style because I know that the more brains and more time the team spends staring at an idea, the stronger the idea becomes. This means that decision-making in groups that I manage tends to be slower because I’m busy cross-pollinating, but I’m certain it means the our output is higher quality because we’ve taken the time consider what the hell we’re doing.

Remember that every person on the team that has a strong opinion regarding the decision, there are probably four other coworkers who just want someone to make a decision so that they can get back to work. We’ve each been part of the silent majority before… it’s the time when you choose to not engage in the heated debate. Maybe because you’re doing actual work or perhaps you just don’t care. You appreciate your silent status as you see the debate rage in the hallway… realizing how much pain, sweat, and tears you saved by staying out of it. When the team is still yapping away two weeks later, you start to wonder when someone is going to step up.

Mandates are the friend of the silent majority. Even if you really annoy the concerned parties, the silent majority will appreciate the peace and quiet once you’ve delivered your verdict.

Deliver

The purpose of this article is not to explain how to make whatever hard decision you need to make regarding the heated topic in your organization. I don’t know what the topic is, so you’re on your own. I will say that if you don’t spend time considering both sides of the issue before you Deliver that your team will know it and your credibility will be suspect. Those on the losing side will wonder why they weren’t consulted and then they’ll start wandering the halls murmuring that you’re either lazy or a tyrant. Ouch.

The goal of the Deliver phase is straight forward. You need to explain to the team that a decision has been made. Sounds easy, right? Well, this is where junior managers blow it. They do a good job of explaining the decision, but they fail convey that this is the decision and further debate is not necessary. A good sign of poor mandate delivery is when the delivery degrades into, yet another, debate of the issues. Delivering a mandate takes moxie… the team has got to leave the room knowing the decision has been made. They don’t have to like it, they may hate it, but they can not leave the room thinking there’s wiggle room in what you decided.

Again, an added benefit of this my collaborative management style is that mandates are less controversial because I’ve already vetted the various flavors of the decision with all the folks who have an opinion. When the mandate (finally) lands, it feels less like laying down the law and more like I’m relaying the results of our investigation. I still piss off those who disagree with the decision, but at least they got their say, right?

Deliver (Again)

Congratulations. You’ve delivered your first mandate and now you’re staring at a room full of heads nodding in the affirmative. Even the folks who have been screwed by your decision are nodding. Well done! There’s more work to do.

All that head nodding is a big ego boost, but the fact of the matter is that each person walking out of meeting has one of three distinct opinions:

  1. YAY! — You are a Great Motivator. The winners will have this opinion of you, still you need to Deliver (Again).
  2. BOO! — You are a Tyrant. Commonly held by those who’ve been screwed. You must Deliver (Again).
  3. YAWN! — What took you so damned long? Silent majority here. Don’t sweat them… this time.

Delivering (Again) might be better called Damage Control, but that makes it sound like you screwed up by pushing the team forward… and you didn’t… maybe. Delivering (Again) is taking the time to individually express your reasoning to the concerned parties — both the yays and the boos. This not only gives you a chance to re-enforce what you mandated, but also gives coworkers the chance to respond in a non-team setting. Expect more venting. In fact, insist on it. If you’re sitting with someone who on the losing side of the decision and they’re still nodding their head, THEY DON’T BELIEVE THE BATTLE IS OVER. If you fail you get this person to open up, you will be mandating (again) in a few short weeks.

Delivering (Again) is not going to quench discontent in your team, but it going to give everyone involve a chance to speak up and that should push your management karma towards Motivator and away from Tyrant.

External Mandates

I’ve been talking about the ins and outs of Home Grown Mandates so far. These are situations where you are the decision maker which gives you access to a wealth of information as well as all of the players. In any decent sized organizations, you are equally likely to be on the receiving end of External Mandates. This is a mandate that occurs way outside of your sphere of influence.

Yes, the tables are turned. Mandates might just randomly show up and there isn’t a thing you can do it about it.

Guess what? The same rules from above apply with one exception. Just like your team, you are going to have one of the three opinions (yay, boo, or yawn) regarding the mandate. Regardless of what your opinion is, you must ask about mandate justification. What was the reasoning behind this mandate? You might have a Yawn-opinion about this, but what about the rest of your team? They might hate the mandate and boy are you going to look lame when you relay the mandate without a clue as why the mandate showed up.

Here’s the rub, mandate justification often does not travel well through a large organization. Either someone in your management food chain had a yawn-reaction to the mandate and didn’t bother to gather a justification or the grapevine has tainted the justification to the point that it no longer makes any sense. Either way, you’re going to be delivering news to your team sans reasoning. This blows. I’m certain that companies which exhibit this poor communication structure are the same ones which have reputations for notoriously tyrannical CEOs. Maybe they’re not tyrants… maybe they’re surrounded by poor communicators. Or maybe they are tyrants. I can’t tell from where I’m sitting.

The good news is that if you ever have to deliver a mandate without the facts to back it up, you less likely to pull a rookie mistake and land your Home Grown Mandate without the reasoning… the justification. You’re also not going to forget to Deliver (Again) because you know that each time you stand in front of your team, trying to be a leader, they are watching and they are listening. They want to know if you deserve the title of manager.

# October 6, 2004 : Twitter : Comments (6)
Management 5 Scenarios for High Velocity Engineering Managers

What To Do When You're Screwed

Cabel Sasser of Panic dropped a shirt off with me shortly before my first presentation at WWDC.

panic rulez!For those of you still using Lynx, the shirt reads, “Hi, I make macintosh software.”

While Jimmy Eats World was ripping the tunes at the WWDC campus bash, I proudly wore the aforementioned shirt all over the campus. Co-workers quickly pointed out, “You don’t make software anymore… you tell others to make software.”

That’s right.

I do.

Let’s get started.

You’re a manager now. Congratulations. Either you sucked at programming and wanted to try a different influence avenue or you’re fed up with every other manger you’ve worked for and now you’re going to REALLY GOING TO SHOW US how it’s done.

I’m here to help.

Your first five years as a manager are going to be full of lessons galore. Lesson #1 begins the moment someone asks you a question and you realize they’re asking you not because you actually know the answer, but because the term manager is in your title and they’ll believe any reasonable answer. Some folks call that power, I call it responsibility.

There are other lessons, as well. There’s the big three: hire, fire, and layoff. All of those are a nice kick in the teeth that’ll be the source of significant insomnia. There’s the little stuff, too. You’ll find yourself saying “We” a lot. You’ll notice you’re repeating yourself… saying the exactly same thing to twelve different people. Some of it’s entertaining, some of it’s dull, but it none of it compares to when you’re Screwed.

The state of being screwed is unique. You know when things are going smoothly because you can arrive in the morning and quietly sip your hot beverage until your first meeting at 11am. Screwed is the oppposite. Screwed is being accosted the moment you walk out of the elevator and being unable to even check your mail… until Winter.

Screwed is mental paralysis.

Screwed is career panic.

Screwed is also an opportunity to hit it out of the park. Overcoming screwed will give you confidence, experience, and respect, but you need to figure out how screwed you actually are and then then figure out and how to fix it. If you aren’t interested in unscrewing yourself, I’d suggest this article is not for you. I’m assuming you have passion regarding your professional career. You want to do more. You want make more money and, if it all works out well, you want to change the world.

Maybe I haven’t been kicked in the shins enough, but it baffles me when I run into folks who are coasting through life. Doing the bare minimum to get by and… enjoying it? What exactly are you enjoying? Hey, maybe your day job isn’t your gig, but I like mine, so let’s begin:

#1) I’m Missing A Document and People are Yelling at Me
Screwedness: Low

Early on the product development process, everyone is talking about writing it down. Marketing specifications, engineering specifications… specs, specs, specs. Milestones are often constructed around these specifications, but, usually, these milestones come and go and no one really gets fussy about missing or incomplete specifications. That’s the good news.

The absence of a particular document really isn’t that relevant to your screwedness. The real question is “Who is asking for said specification and why?”

If the requestor is someone who has a legitimate need for the information, your potential screw-i-tude is high. Someone, somewhere is not able to do their job and that means someone could fail in their work and that’s bad because they’re going to be pissed off and pointing at you.

A tip: Don’t confuse the request for information as a request for a complete answer. You completionists out there do this a lot. “I must answer the question thoroughly and completely; therefore, I must start by selecting a template for the information that best structures my response and BLAH BLAH BLAH”… two weeks later and the requestor has moved on. You have officially missed your window to sound like you know what you’re talking about and, guess what, you’ve also been pegged as hard to work with / unreliable. Way to go.

Larger organizations really believe they need to document more and they’re right. Communication in big organizations is tricky because everyone’s got an opinion and you never know who is going to have a bright idea. Big company policy on requiring documentation is furthered by layers of management struggling to ascertain/measure what is actually going on in large groups of people. (See: Status Reports Must Die)

If you’re feeling screwed by the absence of some important document, again, look at who is giving you that screwed feeling and ask yourself, “Is this an honest request for facts or a management boondoggle?” If the answer is facts then face-to-face communication is always the way to go especially if time is of the essence.

This section reads like I’m anti-documentation which is silly because HELLO I WRITE A WEBLOG. Remember the context of this column, “When you’re screwed…”. I’m talking about situtations when it appears the sky is falling and you need to move quickly. I could easily argue that diligent and frequent documentation is a handy way to avoid sky-falling-situations because writing stuff down is a great way to make information scale… because you don’t.

#2) A Significant Development Tool Does Not Exist on My Team
Screwedness: Varies by tool

There are an endless pile of tools engineers are fond of using in their development process, but there are only four that they really need:

I’ve never seen any engineering organization that hasn’t had some form of an editor and compiler, but I’ve been shocked to find both version control and bug tracking missing when I’ve walked in the door.

If you ever find yourself in this situation, your first job… before you even sit down at your desk… is to get these tools in place and in use or you and your organization will be forever screwed. Any engineering organization with more than two people will fall flat on it’s face as soon as the product development process gains any sort of momentum unless version control and bug tracking are in use.

These tools empower engineers by allowing the entire team to:

You’ll find early on in your management stint that main reason people make the trek to your office is because they need conflict resolution. Once the conflict participants stop yelling, you need to get them looking at facts because facts will ground them and grounded means less yelling. All of the tools I describe above are excellent repostiories of cold hard facts and that can help.

#3) I Can’t Stand My Product/Program Manager or They Plain Don’t Exist
Screwedness: Medium

As an engineering manager, you need to have two significant peers. First, you have a product manager… marketing. This person represents your conduit to your customer and their needs. Second, you have your program manager. This is your process and communication czar.

The program manager role is a bit harder to define because most engineering managers confuse a program manager’s role with their own. A program manager owns the entire process of shipping a product. Think of it like this, you, the engineering manager, hand a DVD with your final product to the program manager and they make sure it shows up in Fry’s in the right box. Don’t think that isn’t a huge amount of work because it is.

Again, both product and program managers are information brokers. For the product manager, they represent the customers needs… they tell you what the customer wants and you build it. Once you’re done, they tell you how it went. The program manager’s information is organizational. For any given question, they know the answer or know who to ask. Good ones are also process wienies which means things just don’t fall through the cracks around them.

Program Manager Sidebar: My strong belief in the role of program manager comes from first hand screwedness. My start-up was twenty folks when I arrived as the first engineering manager. Over the coming two years, we grew to 250 people where I was managing three product lines. The executive management team created the program office around that time and I was immediately suspect. “What do these boobs do? Take meeting notes? Jesus, what a waste.” Wrong wrong wrong. Good program managers are detail drivers. They handle the piles of minutia surrounding a release and you’ll be shocked the amount of time they’ll save the average engineering manager.

If you’re unable to work with these co-workers or if they just don’t exist, you’re pretty much at the same state of screwedness. You’re going to have to do their jobs for them and that means less time to actually be an engineering manager. This isn’t going to feel like screwed because you’ll be busy, but you are, bit by bit, cheating your team and your product out your time while you making sure the box art looks right.

Of the two, a missing or moronic product manager is probably more of an issue since their data affects the work of your entire team. You’ll likely make things worse when, if pressed for time, you declare, “Well, I know what’s best for the customer.” Again, wrong. Unless your product is targetted at software engineering managers then it’s unlikely your opinion is relevant. Sorry.

#4) My Product is No Where Near Done
Screwedness: Less than you think (hopefully)

Let’s first remember that product development team loses their minds the last month of any significant product development cycle. Really. They’re insane. They’ve been staring at this damned product for so long that they’ve developed a serious emotional attachment with the bits and that means irrational, goofy behavior that is not based on reality.

This is you. Mr. Insane Engineering Manager. It’s two weeks until your product ships and you are sure there is no way you’re going to make it. Your claim is, “The product is crap”

Now, there are two possibilities both of which are equally possible. First, you might be too close to the product to make a quality judgement. Your initimacy with your product has clouded your judgement and what you’d consider ready for prime time has nothing to do with what a customer would be happy with it. If, in a moment of lucidity, you realize that this the situation you’re in, it’s best to find a person/party who’s judgement you trust and get a sanity check. You’re instinct will be to go to your QA organization, but they’re likely equally in love with the product and probably more wacked about quality than you.

Maybe your boss? Maybe another engineering manager? I don’t know who, but it’s got to be someone who has not spent the last three months living and breathing this product that’s NEVER GOING TO SHIP. When you do find a designated sane person, they should ask questions like this:

  1. Are the features done? How done? Are they testable?
  2. How many bugs are left?
  3. How many bugs are you fixing on a daily basis?
  4. How many bugs are you willing to ship with?
  5. What’s your bug deferral criteria?
  6. What’s your update strategy?

This sane person’s job is not to decide for you. Their job is to be neutral and to help you frame your decision by asking great questions. As a rookie manager, you’re not going to seek external input because you’ll think asking for help is a sign of weakness and, boy, are you wrong. Asking for help of team members allows these folks to apply their unique experience to whatever the problem might be and that’s how you make better decisions while also building a stronger team. Asking for help is a big deal. Do it. Often.

That’s situation #1… getting a second opinion. This leads us to situation #2 which is, you’re right… your product is nowhere near ready for customers and you’re fourteen working days from shipping. You and your team are charging forward to the ship date, but most everyone is shaking their heads slowly and murmuring, “It’s not ready”.

And it’s not. No need to get a second opinion. You’re still finishing features. QA is sufficiently pissed off and your program manager is crying in his/her office.

Yes, it’s really not ready.

As an individual contributor, your job is to bitch about the situation. I mean that in a good way. Bitching is one way to conveying data and if your manager is listening, they’ll register it as such. Problem is, you’re the manager and it’s now YOUR JOB to make initiate a course correction because late is better than crap.

If this is your first ever course correction, you’re going to believe you’re more screwed than you are. Here’s the truth: Most everyone believes that engineering is lying when they propose a schedule. It’s what fancy word talkers call a truism. If engineering says it’s going to take a month, it’ll probably take three. Ok, maybe lying is a bit strong. We’re actually not lying, but we’re doing the best we can, I swear. We honestly don’t know how long it’s going to take to finish that feature until we’re halfway done.

Organizations insulate themselves in different ways against the lack of engineering certainty. Some product groups build in slip time. Others have mysteriously named milestones POST ship which are the actual ship dates. The point is: If this the first proposed slip for any given product, you’re going to be pleasantly surprised when the product team says, “How much time do you need?” Didn’t know you were playing poker did you? Well, you are.

DISCLAIMER: If you’re interested in building any sort of credibility in your organization, I suggest that slipping your product late in the game is just bad PR. Any good engineering manager + program manager team is going to build in feature and schedule checkpoints where mid-game adjustments are made that give everyone higher confidence in a final schedule. Last minute schedule changes violates Rule #3 of Rands Management No No’s: “No surprises”.

#5) My Company/Job Sucks or Is About To Suck
Screwedness: High

True story. In the early 90s, Borland was taking it on the chin from Microsoft. Borland’s big transition of their office applications to Windows was going abysmally. The Microsoft monopoly was in full force… they bundled their first version of the Office suite and were underpricing the competition. Good-bye Quattro Pro, Paradox, and dBase.

After years of expansion and a move into a (still) amazing campus, Borland was about to implode and I was aware of this. That’s the first step to get yourself unscrewed in this situation… detection… knowing the ship is sinking even though those execs continue to sound eternally optimistic in those all hands meetings. Of course they sound positive, if the rank and file universally believe the sky is falling, those all hands meetings will become utterly devoid of hands.

What’d I do? I jumped ship. I took my engineering title and moved up the peninsula to a now defunct database company. Problem was, the new company was in much worse shape than Borland having imploded about a year earlier. I didn’t know this until my hiring manager who had portrayed portrait of enthusiasm and vision was gone one month after I started. I was suddenly debugging build systems and drinking really bad coffee with a bunch of chronically depressed database developers.

Ooops.

It’s obvious, but there are two parts to getting descrewed when your company sucks. First, detection. There are people still at Borland who, to this very day, are still bitching about that company the same way they were over a decade ago. Let’s call them faux-Bitchers because for all their bitching, they’re never going to do anything about it because bitching about, apparently, is enough.

You are not faux-Bitcher because you’re still with me. You want to do something about your screwedness. You want to make an upwardly mobile move. You want to go somewhere where you’re:

  1. Getting a raise
  2. Getting a promotion
  3. Getting to do something that interests you
  4. Working for a company that doesn’t suck

In my post-Borland move, I succeeded in A and B, but I blew D… and, it later turned out, C. It was my worst career transition ever and it took me a year to get back to a place that I felt I was moving forward. Good managers keep their teams, their products, and their careers full of velocity.

Velocity.

That’s a better term than upward mobility. Constant forward momentum.

How you are going to achieve your own personal velocity is your own deal. My apparently endless stream of management advice is just that… advice. What you really want is my experience, but you can’t have it because there is only one way to get it… you’ve got to put yourself a situation that allows you to get screwed. When you’re deep in it and terrified, maybe some useful acquired advice will pop into your mind or maybe you’ll construct more elegant solution. Either way, you’ll come out the other side moving faster… or maybe slower.

# July 10, 2004 : Twitter : Comments (11)
Management It's better than a poke in the nose

Healthy Tension

As a manager in any software engineering organization, you’re going to be subject to a lot of interpersonal angst amongst the team members. You’ll be walking to lunch and Engineer A is going to be ranting and raving about Engineer B on another team…

“Man that guy bugs me. Have you seen his code? Wow! Unreadable. Totally incoherent. “

9 times out of 10 if you put Engineer A and Engineer B in the same room, you’d be unable to discern that there was an actual issue because they’d treat each other professionally and with courtesy.

Fact is, the angst was faux angst and while there may be an issue there, your primary job was to sit there and be a sounding board. The issue will often resolve itself or just be that… an issue. Where you’re going to need to get involved is where the angst is real and potent and, well, as emotionally charged as I’ve ever seen in hi-tech… the bug database.

Repeating for clarity: A bug database is where people truly develop hate in software engineering organization.

It’s always during the last few weeks of the development when the bugs become the one and only metric the organization is watching to see if the product is going to ship. QA knows this. Engineering knows this. Their days are centered around reloading database queries which show them how many bugs are currently on their plate. More is bad, less is good. Zero is best.

The reason the hate erupts between QA and Engineering is because most software engineering organizations create a healthy tension between QA and Engineering. The tension is based on a simple idea:

These are contradictory goals. Let’s simplify them into declarative statements:

Engineering: We believe we have done our job.
QA: Uh, no you’ve haven’t.

Of course Engineering is going to want to give QA a poke in the nose. QA is telling Engineering they’ve done their job poorly and what wants to admit they screwed up?

For much of the cycle, everyone is so busy designing and developing the product that not much attention gets paid to the bug database. That changes as soon as a graph gets posted on someone’s door which shows the bug arrival rate versus the bug fix rate. The race is on… who is going to win? More fixes or more bugs?

The bug database becomes the plan of record for product and all hell breaks loose because, well, everyone is trying to do their job and it turns out the bug database is the last place they should do it.

If you’ve spent time in a bug database, you know the precise emotion I’m talking about. Read this bug report and reflect:

Bug #52392 - App crashes (Severity 1)

Steps to Reproduce:

1) Click on the application (Build #45)
2) Application crashes

Expected Result:

The application should not crash

Let’s assume this is the first bug report you’ve ever received from this QA person. You’re going to cut them some slack, you respond with:

Engineering: Thanks for the report. Could you reproduce this and send me a crash log?

Three hours later and you receive the bug back with the following information:

QA: Just click on the application and you’ll see this for yourself.

Grrrrrrrrrr. Ok, now your pissed. Who is this boob? Doesn’t he/she realize that if the application DIDN’T EVEN RUN that it would have never even gotten out the build team? And even if it did, every single engineer on your floor would be bitching and moaning about a broken build. WHAT A DUMB ASS.

Can you feel it? The blind rage over a text entry in a database? Boy, are you tense. Take a break and let’s see what happened.

See, the data you need in this bug wasn’t in the steps to reproduce. The data was in a subsection of the bug that you never look at. This tester is a wireless tester and it turns out your application does crash in a wireless set-up and he’s the only who does wireless testing in the building.

Why in the world do you want to hate this guy? Just because he’s doing his job? No… you want this guy beaten because it appears from the bug report that he’s an arrogant twit, but the fact of the matter is, you’re a lazy bug reader.

This is one of a million unfortunate situations that happens in late in a product cycle. Yes, there are truly twits out there (in both QA and Engineering) that should be poked in the nose. Still, when I’m forced to triage the aftermath of a bug war, it’s almost always individuals trying to resolve conflict via a bug rather than getting their butt out of their seat, walking over to the other individual involved, and acting like a human being.

Anyone who has had significant experience interacting with other people via email, instant messaging, IRC… whatever… you know that context is lost when you translate to text. You know that when you really want to understand what someone is trying to say in email, you pick up the phone and ask, “Um, what the hell are you talking about?”

Yes, the healthy tension must exist between QA and Engineer because they do have conflicting goals. Your job as an engineering manager who doesn’t want their team poking each other in the nose is to remind your team that, first, if you’re grinding your teeth in your office as you’re reading a bug, I guarantee, I promise, I swear that you are missing some essential piece of revealing data that is just short walk away. Second, both teams, QA and Engineering, have the same goal. They must ship product.

# May 25, 2004 : Twitter : Comments (8)
Management When done is done.

Heinous

You and your software development team are close. So close. Just a few more bugs and you’re ready to get those bits out there. You can taste it, but… the bugs keep showing up. Five in the morning. Ten in the afternoon. Oh shit, fifteen more during the weekend. Each day… anything more than zero is just bad news.

Not. Shipping. Yet.

One word is going to help you. One word is going to turn the corner from DOING to DONE. That word is Heinous… and Heinous wants to help.

Let’s back up.

To understand the value of a single word, you first need to come to terms with where your brain is at late in the product ship cycle.

You are insane.

It’s true. You are nuts.

I’ll explain, but first we need to be clear about exactly where we’re at in the product cycle. This isn’t the last month of work… this isn’t the last big push. This is the culmination of a huge amount of work done by a handful of people who have been bleeding from the fingertips for the last month.

You and your team, for as long as can you remember, have been living and breathing “the product”. You’ve spent months designing it and months/years developing it, so it’s hard to figure out where you stop and the product begins.

This frame of mind, this intense relationship with a body of code, is not conducive to actually shipping product because you are blinded by your devotion to the product. You want to see your product successful because of what you and your team have sacrificed and OF COURSE you are imminently qualified to fix what ails your product…

Bugs.

The bane of your existence.

You will kill… kill them all because they threaten you and your product.

See? You’re certifiable.

I exaggerate. Your shipping experience may not have been as intense as this, but I assure you if you’ve spent more than six months on a code base that your collective mental panties are in a bunch.

You need Heinous.

Heinous means bad. Really bad. Horrible sky-is-falling bad. Grossly wicked. Jack the Ripper bad. Are you getting this? Good.

Heinous is the word to describe the type of bug you will not ship with. As a responsible parent for your product, you think you will ship with no bad bugs and that’s where you’re loopy. You’re going to ship with tons of bad bugs. More than you’ll be comfortable with. You’re, however, not going to ship with Heinous bugs because these are the bugs which, if found AFTER YOU SHIP, would stop the presses. People would run around the building screaming. Much money would be lost and heads would roll.

I’m not talking crashes… I’m talking massive data loss… horrible operating system hangs… exploding computers. I’m talking Heinous.

Now, you completionists out there are having a hissy fit right now because I’m suggesting that software should ship with bugs and that offends your purist sensibilities. That’s fine. I expect my resident completionists to hold the perfection bar as high as they are physically able, but completionists don’t ship software. Incrementalists do because incrementalists know that better is the enemy of done.

Still, whether you are an incrementalist or completionist, you both need Heinous. Everyone needs a cue to understand that the time of fixing bugs is over and the time of shipping product has begun.

Here’s a hypothetical recreation of a bug triage meeting from my start-up. It’s me (engineering director), VP of Professional Services, Director of Quality, and our Product Manager. We’re going down the list of new bugs which arrived over night… five days until shipping:

Me: “Bug 9744. Moving applicant back to interview state creates garbled text.”

QA: “There’s a workaround, I’m not sweating it.”

ProServ: “There will be training impact, can we get this fixed?”

Me: “It’s about a day of work.”

Product Manager: “This will reflect poorly on us in the press.”

Me: “It’s a day of engineering and a QA slip.”

QA: “We can test it in our current schedule.”

Me: “No you can’t. It’s a significant change… blah blah blah.”

I have just wasted five seconds of your life that you will never get back. Now, multiply this scenario by the other twelve bugs that showed up that night and you’ve got the makings of a nice product slip. Let’s look at the same meeting now enhanced with Heinous:

Me: “Bug 9744: Moving applicant back to interview state creates garbled text. Is this Heinous?”

Them: “No.”

Me: “Bug 9745…”

See? Everyone gets it. Everyone knows that when Heinous is being thrown around, it means WE REALLY REALLY NEED TO SHIP THIS DAMN THING. Maybe it’s a date driven schedule or maybe it’s a strategic ship date. Who knows? You’ve got to get those bits moving.

Some rules around Heinous:

- You must make sure everyone is aware of the definition of Heinous. Not repeating yourself means you are saving time.
- You may slightly alter your definition of Heinous and that’s fine, but use the definition consistently. Don’t tweak it to your own personal agenda — you will lose credibility and no one will listen to you next time around.
- Don’t use Heinous until you need it. There are four or five big freak-outs in any product cycle before Heinous needs to come into play. If you use it early and then non-Heinous bugs start sneaking in, you’ve blown it and devalued Heinous for everyone. Don’t.

Anyone who tells you that developing software is hard is absolutely 100% wrong. The hard part of developing software is actually shipping the product out the door. It’s not designing or coding or testing a product that is tricky, it’s just that everyone on and off the product team has a damned opinion about this or that or how fast or how slow or how it looks or how it feels. Your job until Heinous arrives is to carefully aggregate, listen to, and act on those opinions because, chances are, someone is smarter than you. These opinions will give you a better product.

With Heinous, the discussion is over. The product is done.

# April 19, 2004 : Twitter : Comments (5)
Management Players and Pawns. Pros and Cons.

Agenda Detection

I hate meetings.

Everyone hates them because we’ve all been to so many that have sucked so badly that we now walk into a conference room, sit down… arms folded, and think, “Ok, how long until this one is going to suck?”

And then it does. Time is wasted. Hot air is created. Silent frustrations are confirmed while historic hatred of managers is furthered.

There is a basic skill you need whenever you walk into a meeting which has suck potential. This skill is important in the case that you are a participant or the person running the meeting. The skill is called Agenda Detection.

Simply put, Agenda Detection is the ability to discern:

  1. Typical meetings roles and how meeting participants assume them
  2. Explanation of what these distinct meetings roles want out of a meeting
  3. How to use this understanding to get the hell out of the meeting as quickly as possible.

If you’ve ever been frustrated in a meeting — if you’ve sat there wondering why in the world these people, these managers, who are paid the big bucks to move the company along simply can’t do or say the painfully obvious then keep reading.

The first step in getting out of a meeting is to identify what kind of meeting you’re in. A meeting agenda would help, but as most meetings proceed without one, you’re on your own. Chances are, you’re either in a informational meeting or a conflict resolution meeting.

At informational meetings, big surprise, information is passed on. Think your favorite quarterly all-hands meeting, staff meetings… any meeting where there’s a standing assumed agenda. There are two kinds of participants in these meetings: talkers and listeners.

Roles and agendas in these meetings are simple. Talkers are talking and listeners are listening. Get it? There is no problem to be solved other than the transmission of information… that’s it. The quicker it happens, the sooner everyone is back to work.

You can quickly identify those folks who don’t get this. They’re the wack jobs who always ask the same (or random) question during an all hands with the hope that simply by asking, they’re going to change something. It’s a noble act… speaking your mind in front of all your peers. It’s a waste of time. This is an informational meeting, people. The talkers are here to pass on whatever organization knowledge they need to so as to prevent a rebellion. When the wack job speaks up, everyone who gets the nature of the meeting is thinking, “Ok, another useless question which is going to keep me here longer. Crap.”

I’m not saying that rocking the boat during the required Q&A session is not feasible in these meetings, it’s just not efficient. Folks are there to nod, not solve problems. Where the wack job should be speaking up is at our other class of meeting, conflict resolution… that’s where they could influence folks because people go to these meetings to solve problems.

At a conflict resolution meeting, some problem needs to be solved. Apparently, it could not be resolved via email, instant messaging, or hallway conversations, so some brihg tfellow decided to waste some more time in a face to face meeting where the bandwidth is high and the time wastage is significant.

Agenda detection in the conflict resolution meeting is more complex. To see it in action, let’s create a meeting:

4pm, this Tuesday. You, Joe Sr. Engineer, two other random engineers, one product management person, and a program manager. The program manager called the meeting to solve a problem. See, the Sales folks sold something that your company does not make. You’re here to explain how much it’d cost to build this thing that you’ve never built before but that’s already been sold. Been here? Thought so.

Agenda detection starts when by first classifying the players. There are two major types that you need to identify: Players and Pawns. The simple distinction between Players and Pawns is that Players want something out of the meeting. This is their incentive to participate. They’ll be leaning forward, actively nodding, and barely able to hold themselves back from spilling their agenda all over the table.

Pawns are either silent or instruments of running the meeting — in any case, they’re adding very little to the meeting and can be removed from consideration as a means of getting out of the meeting. The term Pawns is not intended to be derogatory… Pawns very well might be running your company, but in meetings, they just don’t contribute… it’s not their key skill.

Bucketing of Players and Pawns is simple, you can do it with the attendee list and a bit of organization knowledge. Let’s try it with our hypothetical meeting above.

First, you can assume all the engineers are players — they’ve got technical knowledge they may throw on the table otherwise why were they invited? The product management person is also a player as they represent sales folks in this meeting. The program manager is a pawn… they’ll make sure action items are recorded and that the meeting ends on time.

MEETING BAIL TIP #1: If you’re sitting in a meeting where you are unable to identify unable any Players, get the hell out. This is a waste of your time. These are meetings traditionally called by wind bags who like to hear themselves talk, but hold no real influence over the organization/product/whatever. Unfortunately, if you’re new to a group, you need to get burned by the wind bags a few times before you learn to avoid this totally fucking useless meetings. It’s tough being the new guy.

The next step in agenda detection now kicks in as we look at the Players. This is when you figure out each Player’s position relative to the issue on the table. For whatever that issue is, there are two subclasses of Players: the Pros and the Cons.

The Pros are the players who are currently on the winning side of the issue. They’re getting what they want and are not incented to negotiate. Heck, they don’t even have to be there… they’re just here to see the Cons squirm. Yet, they are there, they’re at least willing to listen to the Cons, right? Maybe.

The Cons, clearly, are the ones who are being screwed. They’re likely the ones who yelled loudly enough to get the meeting set-up in the first place. Cons are usually easy to pick out because they’re expressing some degree of pissed-off-ed-ness.

MEETING BAIL TIP #2: Like our Player requirement, both Pros and Cons must be represented for any progress to occur otherwise you’re just going to talk and talk and talk. You’re guaranteed the Cons are going to be present because they’re the ones who are screaming and shouting. If you want the meeting to actually produce something useful, the Pros must be represented. The specific Pro does not need to be in the building, but they must have designated a proxy otherwise the Cons are going to bitch, heads will nod, and nothing will happen.

Let’s take a stab at identifying the Pros and Cons in our hypothetical meeting.

In the example above, it’s clearly engineering who is being asked to build a product THAT DOES NOT EXIST. They’re pissed and they’ve called this meeting to quantify this frustration. Hello Cons.

As we’ve already identified our program manager as a Pawn, we can only assume that our product manager is the Pro. But wait, now you’re in this meeting and she sounds like an engineer. “Those god damned sales folks. What the hell are they thinking? This is the last time blah blah blah…”

Wait, our product manager appears to be a Con? Does this means Rands thinks I should pull the rip cord and get the hell out? No, your product manager is the Pro… she’s just bright. A common tactic of a good Pro is to not acknowledge that they’re the Pro. This means that they don’t have to actually take the heat for whatever the conflict is. The real Pros aren’t in the room — the real Pros, in this example, are the sales folks who cut the deal to sell the product that doesn’t exist — except they’re out in the field cutting more unachievable deals. The product manager is attempting to fake out the engineers in the room by saying, “Hey, this is a tough problem that THEY have put US in… what are WE going to do?” Brilliant bait and switch, no? Don’t sweat it. They make less than you.

The stage is set. Our Pawns have been filtered out. Our sneaky Pro is nodding.. placating with her feigned commiseration, the Cons are yelling and, yes, you’re still in the meeting.

Believe it or not, the hard part is done.

If you’ve paid attention, you’ve got a pretty good map of who is who, where the whos are… now all you need to do is figure out what the whos want. The Pawns don’t want anything — they were just happy to be invited. The Pros are there to show off their complete and utter ownership of the issue… they’ll leave whenever, the sooner the better.

So the reason you are sitting there is the Cons. What is it that they want?

Stop. You’ve got some meeting in mind, some horrible meeting where the issue is so complex that there is no way the simple identification process I described could apply. Wrong. Your jumping to solve the issue and there is where everyone fucks this up. Who cares about the issue? Do you know who matters in whatever horrible meeting your sitting in? Did you take the time to identify the people who actually care? The ones who can make a difference? If you haven’t then you deserve every useless minute of that meeting.

I am convinced that a majority of the meetings on this planet go long and do less because the people sitting around the table simply do not figure who the hell they’re talking to and what they want.

Yes, the Cons do want something. You’re going to meet their needs in order to get out the door and their needs are simple… so simple you’re going to laugh. The Cons need a plan. Some assurances there is a plan which is going to somehow address whatever the issue is. Doesn’t matter if that plan comes from the Pawn, the Player, the Pro, the Con… someone needs to synthesize everything into constructive next steps, communicate that TO the Cons, and you’re done. You’re out the door.

Doesn’t need to be a great plan or a honest one or a complete one. Cons will not let you out of that meeting until there is the perception of forward progress (“a plan”). If you’ve scheduled a hour and that hour is up, you’re thinking, “Well, that’s one way out the door”. Again, incorrect, because the Cons are returning to their desks and scheduling a follow-up meeting where the organizational ineptitude is going to continue.

MEETING BAIL TIP #3: You very well might have the requisite Players & Pros/Cons, but, then again, you might have too many. If it’s thirty minutes in and you still can’t figure out what the issue is, it’s time to go… too many issues. Someone who cares more than you needs to distill this chaos down to a coherent statement so the Pros/Cons can argue about one thing.

Meetings are always going to be inefficient because language is hard. Getting folks in the same group, with the same organizational accent to talk coherently to each other is hard enough. Meetings give us the opportunity to include other organizations with other accents. This makes the language chaos complete, but, now, you don’t care. You don’t need to know what they’re saying because with Agenda Detection, you can figure out what they want, get it for them, and get the hell out.

# February 8, 2004 : Twitter : Comments (15)
Management

Status Reports 2.0

At a start-up, there are two organizational inflection points which drastically change communication within the organization. The first change occurs around fifty or so people — this is the moment when, if you’re an early employee, that you first see someone in he hallway that you do not recognize.

mouth o' snakesThis is troubling to you because, until that point, not only knew everyone on a first name basis, but you also knew what they were about… what they were responsible for… what floated their boat. Now, there’s an unknown quantity in the building.

This awkward, but necessary evolution of the organization, passes. You accept the fact the company is growing and you decide to focus your attention just on your group… who cares what those schmoes over in the support group are doing, anyhow? You’ve got an engineering organization to build.

The second organization inflection point happens somewhere around two hundred… two hundred and fifty. The problems identified during the first inflection point are serious problems now. Fiefdoms have been created in your organization and they’re not talking to each other. What made your organization great early on, great communication, is still going on.. it’s just going on inside of each of your organizations and not across them.

Executives in these larger organizations may be the first to recognize this when they’re meeting with these different organizations and get the impression these individuals teams don’t work for the same company.

So, the executives panic. They have an offsite where they talking about cross-functional communication and teamwork. They come back, promote some would-be-holistics to be Directors to improve communication, reorganize the company, and then… they do it… they curse the organization with busy work… busy work in the form of Status Reports.

I’ve managed a variety of different sized organizations. In the larger ones, inevitably, I’ve had a meeting with my managers where I’ve needed to explain what my Status Report policy is. I’ve always started this conversation with this same preface, “I’m sorry, but we’ve got to do Status Reports.”

Why am I apologizing? Clear communication is a good thing and status reports are just good, clean communication, right? No, they’re not. The reason I’m apologizing is because by instituting or supporting a Status Report policy, I’m admitting, “I do not have a better solution to facilitating good communication than busy work in the form of Status Reports. Sorry. I’m pathetic.”

The idea of Status Reports is not a bad one. Generally, I ask for the following information on a weekly basis. Highlight, low lights, and any open issues. Pretty simple. Think of it as a weekly litmus test. The first few weeks with a new group, I tend to get stellar Status Reports from the team. Lots of detail… lots of energy… lots of content. It’s clear the manager and the team spent time on the report.

Two months later, Dullsville. The very same people who were generating content rich Status Reports are now sending bullet lists that really don’t change on a weekly basis. I stop reading them, they stop writing them, and we’re back in the Land of Poor Communication where we perpetuate the fact that everyone hates Status Reports.

This needs to be fixed.

To me, their are two major consumers who need Status Reports. The first consumers are the executives/overseers/managers. This is your senior management crowd who want a high level overview of where all that money is going. You want to keep this group in the loop because they sign the checks, they can be very good at discerning warning signs from seemingly vanilla Status Reports, and they also usually are big influencers on strategy… this is key when you want them on board when you’re proposing that two month slip to improve quality.

Due to the fact these folks see a lot of Stats Reports, there’s a requirement for the data to be somewhat normalized via a familiar template otherwise they’re going to get frustrated spending their time figuring out what information is being conveyed rather than acting on it.

The other major consumer for Status Reports is, well, everyone else in the company. Actually, let me rephrase, the other consumer is everyone else in the company who wants to read your status report. I’ll explain…

Right now, you probably send your status report to some group of people or a mailing list which goes “to the right people”. The definition of the “right people” is likely based on role in the organization… the managers… the leads… whoever is supposed to have cross-functional visibility.

Here’s the problem with this group you’ve selected.

Let’s say you’ve had an open issue on your status report for four weeks now. It’s gone on long enough that you manager is starting to bring the issue up at your 1:1 and she’s getting frustrated that your answer to “What progress has there been?” is SHRUG. The correct answer to your four week open issue is sitting in the head of JoeBlow Engineer who sits nowhere near you. He is completely outside of your management food chain and he can save your weeks of effort and possible executive embarrassment. How in the world are you going to get to this guy?

Sure, if you’ve got a solid list of recipients for your Status Report, there’s a good chance that someone might make the connection between your Open Issue and JoeBlow, but, chances are, that manager has grown jaded about Status Reports JUST LIKE YOU.

You’re waiting for the punch line here, you think I’ve got some solution and, well, I don’t. What I do have is a rough knowledge of many of the emerging information management tools and I know there is a solution which:

- Makes it easy/attractive for larger organizations to share their information
- Provides a facility to publish scheduled structured reports to executive-types

Let us first talk about two tools:

WIKIS

Wikis provide a solid, flexible backbone for information gathering and distribution, but they are geek. Average computer users will not find them accessible. This means that any solution based on Wiki technology will mostly benefit engineering. I’m ok with that.

Wikis intentially don’t provide structure which means chaos rules. That’s great for a random mix of evolving information, but, at the end of the week, someone has to generate a Status Report and that person’s life will be easier if they don’t have to do a damned thing.

My gut feeling is that while Wikis are a great tool for organic information evolution, they’re not going to play nice in the Status Report world. Not only because of their lack of structure, but I believe the content would be biased the moment those who provided content discovered the Wiki was being pruned for Status Report data.

WEBLOGS

I can see three possible implementations here:

1) Everyone on the team has a weblog
2) “Leaders” have weblogs
3) Project or aggregate weblogs

Weblogs don’t have the level of collobartion has a Wiki, but they can be more structured. Plus, a variety of linking technologies varying from simple links to TrackBack technology provide some of the interconnectiveness that Wiki’s do so well.

A big issue with the weblog is initiating that first conversation within it that doesn’t sound like, “Hey guys, we’ve got a team weblog now and, well, speak up so I have to do less work on status reports.”

There needs to be some creative incentive for individuals to write stuff down. For the Wiki, there is the promise that if you write it down, maybe you can avoid future lame redundant questions. For the weblog, the timely conversational style of the medium keeps the content focused on news of the moment and that’s really the question; is news of the moment interesting to an engineering organization?

What I’m curious about is if anyone has had any success using web-based collaboration tools as a means of augmenting or replacing status reports. I know Wikis have successfully emerged as semi-structured information repositories… have they evolved into anything? How in the world can I get out of writing Status Reports?

# November 20, 2003 : Twitter : Comments (20)
Management

Thingdom

My all time favorite line from The West Wing is, “We’ve got a thing.” There are variations of this favorite line which all revolve around the same word. “Is this going to be a thing?”, “Have you heard about the thing?”, “So, here’s the thing.”

I immediately applied a generous helping of Thingdom to my work day. My staff meetings are now laced with blissfully vague references like “It’s too early to tell, but we may have a thing” or “She’s working on the thing and there is no telling when she’ll be done.”

There are two camps when it comes to Thingdom. Camp #1 has stopped reading this article already because they’ve grown frustrated with pool of ambiguity this article is swimming in. RANDS HAS BLOWN A GASKET. Camp #2… ah… Camp #2… what I love about Camp #2 is that you precisely know what I’m talking about and I have yet to actually say anything.

Aaaaaaaaaaaaaaaaaaah. Thingdom.

Thingdom when used in the White House, your work, or your home is a state of mind. The word itself is not important. What is important that it’s used in a context rich environment — that’s thingdom nirvana. I’ll explain.

It’s your staff meeting. You’re running down your list of interesting data points for your team. Your hit the tenth item and realize that it’s important to dwell on this item. For this example, it is not important what the item is, it’s important that you are able to recognize/prioritizes its value. So, you say, “I think we’re going have a thing here.”

What have you said? Content-wise, not a helluva lot. Context-wise, well, it depends on how well your team communicates. If you say, “We’ve got a thing” and everyone immediately snaps out of the staff-meeting-glaze, you’ve got a context-rich team environment. The team heard the boss identify the thing as a thingable thing and they’re ready to roll.

However, if the team stared blankly at you and each other when you landed the thing, well, I’m sorry… you’re going to have to spell out the consequences, piece by piece, to your team if they don’t get started on thinging that thing. Maybe the lesson will improve their thingdom identification skills. Maybe it won’t.

Thing-enabled teams are more efficient. They better understand sub text, nuance, politics, soft skills… the list of skills is extensive and in my years of managing people, I’ve found it’s a skill set that no one can teach. When I interview, I’m looking for the thing. When I meet you in a bar, I looking for the thing. On Sunday morning, when I’m surfing weblogs, it’s all about thing.

# November 16, 2003 : Twitter : Comments (5)
Management

Inwards, Outwards, and Holistics

As already discussed, Managers are not evil. They’re often just stuck in translation hell where they need to say one thing in one way to one team and say the EXACT same thing to another team in a different way. This constant verbal tapdancing looks sketchy to you, the Average Joe, and you start to wonder, “Hey what does that guy do all do in those meetings anyway? Do he do any ACTUAL WORK?”

Yes.

There are all sorts of intimidating titles surrounding the management caste. Engineering Manager, Senior Engineering Manager, Director of Enginering, Vice President of Engineering, Chief Technology Officer. While these names are useful in determining where a individual lies in the food chain, the names are merely hints as to what that person actually cares about… and you should care what they care about. Your boss and your bosses boss effectively sign your paycheck every two weeks and that means food. Sure, you can leave and go somewhere else, but there’s another manager there waiting for you with their own obscure agenda.

There are three distinct classes of managers, each with their own agenda. The common names for these classes are first line manager, middle manager, and executive/senior manager. Again, these names do a good job of giving you a clue where your manager sits on an organizational chart, but they don’t tell you what they actually do… how they are motivated… we need a different set of names for that. We need a set of names which don’t confuse us with an implied hierarchy.

INWARDS: These types of managers are generally responsible for a small team of folks working on a single product or technology. An Inward manager’s vision is focused on their team… what and how they are doing. While they’re aware there are other things going on in the organization, they don’t tend be involved with external shenanigans unless it directly affects their team.

HOLISTICS: Traditionally the middle layer of management. The vision of Holistics is across the organization. While they are likely managers of managers, their vision is across the company. They are constantly trying to figure out what the hell is going EVERYWHERE in the organization. This gives the impression that they are spread thin and/or constantly busy and they are, there’s a ton of information moving around in your average sized company.

What Holistics are looking for is strategic advantage. If they’ve done their job, they’ve hired rock star Inwards to get the products built to specification and on time so that they can focus on figuring out what to build next and how to get the resources to do so.

OUTWARDS: The senior manager. VPs, CEOs, and what not. The biggest misconception regarding Outwards is what they care about. You’d think their #1 priority would be the care and feeding of the company. Wrong. The well being of the company is, ultimately, the responsibility of the Holistics. They’re the ones who are spending all the time sniffing around the hallways, gathering internal competitive intelligence, and enacting new policies.

Outwards’ vision is focused on the outside world. They care about the public perception of the company, the company’s relationship with its customers, the financial community, the world. That’s why they’re never at headquarters, they’re off telling other people what a great job all those Holistics and Inwards are doing. This is not to suggest that Outwards don’t care about what’s going on inside the company on a day-to-day basis, it’s just not the their job to maintain it even though they are accountable for it. Tough gig.

Now that you’ve got a rough idea of the different management types, let’s talk about how it specifically affects you:

- While I’ve indicated how real world titles relate to these classes, they may not translate to your manager. You might be working for a manager who thinks he’s Holistic when he really should be Inward. This means they’re out combing the hallways looking for strategic advantage when they really should be paying attention to you, the senior engineer who has indicated, “There is no way in hell this product is going to ship on time”.

- Holistics are constantly searching for strategic advantage. There is a spectrum here with “advantage for the team” on one side and “advantage for the manager” on the other. Holistic managers who spend all the time looking for advantage for themselves are called “players”. These people are going to screw you at some point.

Similarly, Inwards who have been forced into the Holistic role are also going to screw you, but not because of any action on their part, but due to their inaction. They are Inwards, they don’t care about the political intrigue over in Building 27, they want to design and ship product, they want to dive into the details. Problem is, the political intrigue over in Building 27 will ultimately determine that your product is irrelevant. Now you’re out of a job because your manager’s manager didn’t attend that cross-functional meeting. Sorry about that.

- The idea of micromanagement is easier to understand with these classes. When you’re being micromanaged, it means two things. First, you are doing a bunch of work that you feel is unnecessary. Second, you feel the person asking you to do is being unreasonable. You’re right on both counts. Busy work is usually the result of poor planning by someone who ISN’T DOING THEIR JOB. Maybe it’s an Outward who gets panicky at the end of release cycle and starts acting like an Inward. Who knows? The point is, a manager is crossing from one responsibility threshold to another and that just confuses everyone. WHY AM I SENDING A STATUS REPORT TO CEO?

- The distinctiveness of these different management classes gets very blurry in smaller companies. The Holistics tenancies tend to be absorbed into both the Inwards and the Outwards. Translation: middle management vanishes in start-ups.

- Once an Inward manager has glimpsed/groked the responsibility (read: power) of the Holistics and the Outwards, they’re going to be motivated to head in that direction for some duration of time between right now and the rest of their lives. Recognizing that your manager is ON this quest is important because, well, they might not be there when you come in to work tomorrow. Plan accordingly.

Conversely, many seasoned Inward managers might be ex-Holistics and Outwards. This means they played game and decided to bail or maybe they were chewed up and spit out. Personally, I think these type of Inwards are phenomenal employees because they have a discernable agenda. Holistic managers and Inwards transitioning to Holistics have a lot more enthusiasm, but they’re hungry for your job. This is also a good thing, but it means you’ve got to run a lot faster.

# September 5, 2003 : Twitter : Comments (4)
Management

Incrementalists & Completionists

I recently got into minor war of words with a co-worker regarding the proper solution to a problem with one of my products. As an aside, let me say that email is never ever ever never ever the right way to resolve controversy. Too much subtly is lost when you’re YELLING IN ALL CAPS. Don’t waste your time solving problems in email… stand up… walk down the hall… and look the person in the eye. You’ll live longer.

ANYHOW.

What was intriguing about my email repartee with the co-worker was that we weren’t disagreeing about whether or not we should do something about the problem. We’re arguing about how much we should do. The disagreement reminded me there are two distinct personalities when it comes to devising solutions to problems: Incrementalists and Completionists.

Incrementalists are realists. They have a pretty good idea of what is achievable given a problem to solve, a product to ship. They’re intimately aware of how many resources are available, where the political landscape is at any given moment, and they know who knows what. They tend to know all the secrets and they like to be recognized for that fact.

Completionists are dreamers. They have a very good idea of how to solve a given problem and that answer is SOLVE IT RIGHT. Their mantra is, “If you’re going to spend the time to solve a problem, solve it in a manner that you aren’t going to be solving it AGAIN in three months.” I used to think that architects were the only real Completionists in an organization, but I was wrong. Architects are the only RECOGNIZED Completionists in the company, but the personality is hiding all over the place.

Rewind to my email situation. The actual problem is irrelevant, but here’s the background. The co-worker discovered a problem in our product and reported it. I responded and suggested an minor improvement which didn’t solve the core problem, but was achievable given our schedule. The co-worker responded with “Why do this if we don’t solve the problem”. I responded, “We don’t have time to solve it and something is better than nothing.” Co-worker, “This is less than nothing!” Insert stunned silence.

Remember, the co-worker identified (correctly) the original problem. Why in the world don’t they see the value of my solution? The reason is, this is a Incrementalist doing battle with a Completionist. This isn’t the battle of wrong versus right, it’s the battle of right versus right. Bizarre.

How does anything get done with Incrementalists and Completionists arguing about degrees of rightness? Well, first, limber Incrementalists can switch teams. They’re opportunists and when they see that acting like a Completionist is a good move and, more importantly, it’s an achievable move, they’ll step up to the Completionist plate. Once they’re there, it’s likely they’ll engage a Completionist to do the heavy lifting, but the Incrementalist will drive because THEY CAN SEE THE PLAN FROM SOUP TO NUTS. This is a big deal for Incrementalists because they normally can’t see past their next meeting… getting them on-board with the “big picture” gives them a sense of foundation they don’t usually have.

Conversely, effective Completionists know when to let the Incrementalists poke around and do their thing. Completionists recognize where this Incrementalists with their rapid-fire buzz-speak fit into the corporate culture and they embrace their mania because they know it’ll help with their Completionist agenda. This, too, is a big deal because Completionists spend much of their lives shaking their heads, staring at the floor, muttering, “Boy, could they fuck this up more?”

A healthy population of both Incrementalists and Completionists is essential to a corporate agenda. It’s not only because they both represent groups that “get stuff done”, it’s also because they are going to argue, but it’s the argument you want your teams to have. It’s not “Should We or Shouldn’t We”, it’s “Let’s do this thing, let’s make sure it gets done, and let’s make sure it get’s done right.”

# August 5, 2003 : Twitter : Comments (38)
Management

Managementese

One of my teams is facing a big fat decision regarding future product direction and the process has split the team in half the “Yes We Shoulds” and the “No Way in Hells”. The manager of the team is facing a minor rebellion and spending much of his time trying to drive the team towards the “right” decision.

A few days ago, I walked by his office and he was talking with one of the “No Way in Hells”, trying to influence them onto the other side of the fence. I overheard a blurb of his conversation, “I think it’s a key decision and I’m asking you to think outside of the box…”

I cringed.

Management speak.

Walking back to my office, I thought about my negative reaction to the term “outside of the box”. What does that actually mean? Well, it means something like “don’t restrict your thinking”, but when my boss says it to me, I hear, “I’M A MANAGER and YOU SHOULD THINK CREATIVELY.” No, that’s not right… what I hear is, “I’VE STOPPED THINKING and I AM USING THROW AWAY PHRASES THAT OBSCURE WHAT I MEAN”

Barfola.

As I sat in my office, a project manager came in for a 1:1. With the observation fresh in mind, I attempted to monitor all my usage of managementese during our half hour meeting. Here are my offenses:

“Can you CIRCLE BACK with her…”

“I want to DOUBLE CLICK on that and…”

“These are the ACTION ITEMS…”

What I learned: I’ve turned into a total dorkwad manager and can no longer communicate like a normal human being.

One of my favorite books on software construction is Steve McConnell’s _Code Complete_. In the second chapter, McConnell describes the richness of language around computer science:

“Computer Science has some of the most colorful language of any field. In what other field can you walk into a sterile room, carefully controlled at 68 degrees fahrenheit and find viruses, Trojan horses, worms, bugs, bombs, crashes, flames, twisted sex changers, and fatal errors.”

He continues:

“A software metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer, it tells you how to look for it.”

With this advice in hand, I’d always assumed that management metaphors fell into the same bucket. They don’t.

Managementese is the language which is learned, evolved, and spoken by managers. For communication between managers, it’s a convienent, high bandwidth means of conveying information. Chances are, when you say “double click” to a fellow manager, they understand you are suggesting that they should carefully check the work/task/whatever.

When you say “double click” to an employee, they know what you’re talking about, but they also know that you’ve just self-identified as a manager by flaunting some mumbo-jumbo in front of them. Why didn’t you just say what you actually meant? Are you sure they actually understood what you meant? Management metaphors obscure meaning and confuse those who aren’t lucky enough to be managers.

There are unique spheres of language which exist at each part of the corporate organization chart. Inside of the sphere is the language which is unique to the job. Engineers have one, marketing has another, and sales has yet another. In each of these groups, there are the managers who must speak their native language as well as be able to translate between spheres in order to get the job done.

Managers are hubs of communication, the better they communicate across these sphere boundaries, the more people they can communicate with, the more data they have, which, consequently leads to better decision making. Ultimately, stronger communicators make more informed decisions and, hopefully, are more successful because they waste less time wondering what to do.

Out of context use of language leads to one thing — confusion. Rather than conveying the information they wanted and getting to the task at hand, a manager who bumbles their communication is going to end up doing it again a week later. Even worse, maybe the painfully confused team isn’t going to say anything about their total lack of direction and the manager is going to be in real damage control mode weeks later.

In high tech, we’re all in incredible fucking hurry. We’re working against an unreasonable deadline, we’re over committed on features, and, now that times are tight, no one is paying for pizza on weekends. As a manager, you’re job is that of a bullshit umbrella. You need to decide what crap your team needs to deal with and what crap can be ignored. That means you need to rapidly acquire information from a variety of people… In that rush, managementese can help you talk with your fellow managers to figure out what the hell is going on, but you’re only half done. You still need to communicate to your team.

This can be tiresome because you, of all people, are absolutely sure what you’re saying. This is why you might be tempted to use the readily accessible management metaphor laced language which you’re familiar with. Don’t. Think back to when you were the junior grade programmer and that first layoff came around… and you were wondering, what’s a layoff? Am I being fired? If so, when? And why?

95% of the people in a big company simply have no clue what corporate machinations are going down and how they might affect whether or not they’ll be working in the next six months. How you will be judged as a manager by your team is based on how you communicate with them. That’s not just taking the time to have that QUARTERLY ALL-HANDS, it’s understanding what they need to hear and being able to say it in a way they’ll understand.

# June 27, 2003 : Twitter : Comments (14)
Management

To-Do Lists

Somewhere between individual contributor and middle management, it became essential that I have a to-do list. I resisted this for years, secretly hoping that I could keep track of all the crap I needed to do in my head or an a convienently located post-it note, but then stuff started spilling all over the floor and I started getting yelled at.

Enter the to-do list.

After trying out many different tools and processes for tracking to-dos, I’ve reluctantly settled on using an Excel spreadsheet. Each to-do contains the following information:

WHAT:
The to-do

PRIORITY:
0 - Now (must do today), 1 - High (this week), 2 - Medium (Whatever)

TEAM:
Which team is the to-do related to

STATE:
I’ve recently added this to the spreadsheet because I needed finer grained control that Priority gave me. Currently, I have three states: NEEDS ACTION which means “move on this”, TARGETTED which means “action has been taken, next step is NOT mine”, and BLANK which means “Uuuuuh, need to triage this”.

NEXT STEP:
If the to-do has been triaged, what’s the next thing that needs to be done? This also gets used a lot for random notes.

SUBMIT DATE:
When the to-do was submitted. I used to highlighted issues based on how many days had passed by submission, but other than adding a lot of color to the spreadsheet, I mostly ignored it.

EXECUTIVE:
This is a boolean. True means executives care about the issue, False means the opposite. This is basically an acknowledgement that Executives, by definition, care about seriously random stuff and it’s more important to aggressively follow-up on the issue rather than debate why they care about it. Separating this means I can leave priority as a representation of my opinion rather than being artificially inflated by an Executive fire drill.

At the time of this writing, I’ve currently got 73 active to-do items on my spreadsheet… 21 which I’m supposed to handle today. That’s about the norm.

I’m content with my to-do set-up because Excel is flexible tool and as I my process changes, so can it. I heavily use the filtering and sorting features to slice and dice my to-do list throughout the day to make it appropriate for the team/people I’m dealing with, but I’m wondering out loud what other people use to track their to-dos. Surely, someone brighter than me has come up with a more robust solution/tool.

# May 8, 2003 : Twitter : Comments (13)
Management

Definition of a Bad Bug

My favorite part of shipping a product is crunch time. It’s the month or so before a major release when you’ve acknowledged that you can no longer delay the inevitable — you must ship this product.

What’s gratifying about crunch time is the velocity with which the product team moves. Decision-making occurs in the hallway. Meetings which used to be an hour shrink to twelve minutes so folks can get “get back to doing real work”. White boards are written on… food is delivered at @ 10pm. Families are ignored.

Invariably one of the biggest decisions that must be is, “whether or not we can ship with this bug”. Hundreds of hours will be spent on bug triage and a ton of time will be wasted by folks defending their favorite bug. To help simplify this, I offer the criteria I use for defining a “bad bug”. A tip of the hat goes to Pac-man who originally mentored this into me.

1. Is it heinous?

First, you must acknowledge that there are bugs when you ship. That is a fact. Can this bug be one of them? Would we spin a quick re-release if this bug were discovered a week after ship? If YES is the answer to all of these questions, you move to…

2. Do we understand the bug?

Why is this bug occurring? What changed in the product to introduce it? If you get past #2, YOU’RE NOT EVEN HALF DONE YET… Deciding to fix a bug and actually producing a fix are two drastically different events. Everything is supposition until the engineer comes back with a fix in hand. This leads us to…

3. Do we understand the fix?

For #3, you’re really after secondary and tertiary effects. Ask yourself, do you really understand all the ramifications of the fix? Really really? Really like my next four raises are dependent on it?

The types of questions you ask for #1 through #3 will vary depending on the type of project you’re developing, but of the main questions, however you define them, should be asked for each bug late in the game because any change to the product is risky.

I love when an engineer says, “It’s just a string change!”. Sure, that’s a pretty low risk change, but getting the product out the door is a hell of a lot more than just making sure it compiles on engineering machine. Did the change get correctly submitted to CVS? Are we sure this is the only change submitted? Does the new version build for the build engineer? Wait, is it localized? I could go on and on with examples of places that folks can fuck up the product with a simple string change.

The goal for any product whether it’s an operating system or a consumer application is to get to a steady state where folks stop messing with the bits. It’s only then that your qualification organization can test against a know quantity and every single change to the product increases the risk that you’re no where near ready to ship.

FYI, for comparative purposes, the catholic catechistic criteria for a Mortal Sin is:

1. Grievous offense
2. Sufficient reflection
3. Full consent of the will

# April 10, 2003 : Twitter : Comments (6)
Management

Reorgs for the Average Joe

You’ve been here…

You get a random email from your boss that you need to meet with him urgently at some odd hour of the day. You sit staring at the email, wondering what could be up. No rumors of layoffs are in the air… the company is hitting it’s number this quarter. You don’t believe you’ve done anything to merit a “talking to” outside of your regularly scheduled one-on-one, so… what’s the deal?

The time comes for the meeting and you decide to not bring your laptop or your notebook. When you walk in your boss’s office, you look into his eyes and immediately know…

You’re about to be reorganized.

My boss was fairly good about it. He came right out and said that part of my group was moving. He explained the justification and asked me for my thoughts. We chatted a bit more and then he blew it, “I held off from telling you because things are changing so much and I didn’t want to jerk you around. Things have now settled down.”

Hah. Right.

Before we rip on the boss, I’ll explain what exactly a reorg is and offer some advice for the Average Joe on how to weather the chaos. First, a reorg is not a layoff. Layoffs can occur as part of a reorg, but they are a side effect, not a cause. Tips and tricks for dealing with a layoff is an entire other article. Reorgs are when teams and products are shifted around in order to account for some external change. What kind of change? Who knows. Maybe the market has shifted or maybe the economy is crap. The point is, someone, somewhere in the executive chain decided, “We need to make an adjustment in the organizational structure”.

Below are some useful rules to pay attention to during the reorganizational chaos as well as some tips and tricks for surviving them.

RULE #1: News travels at different speeds & people are paranoid

As mentioned above, reorgs start to serve a single purpose and then the political intrigue kicks in. From the moment an executive says “reorganization” until days after the reorg has actually occurred, the company rumor mill kicks into high gear. Who is going where and why? Are there layoffs? Why is it happening and when?

There are truthful answers to all of these questions and then there are rumors. Particular hot tidbits of can travel through the organization like wildfire even when a reorg is being kept on the down low because people are paranoid and want to know what is going on. These tidbits will confuse you not only because you won’t be able to discern the fact from the fiction, but also, the information will travel at different speeds depending on their journey through the organization.

Here’s the scenario. When your boss finally breaks down and tells you, “It’s settled. Your organization will not be touched. Don’t sweat it”, you’re going to be relieved. Problem is that it’s also likely that someone, somewhere discussed potential, unrealized changes in your organization and when that fact find it’s way to your desk several days later via tip from a close friend, you’ll be wondering, “What isn’t the boss telling me?” Guess what, now you’re paranoid.

This sea of fact and fiction swirling around at different speeds is the biggest problem with reorganizations. A bungled communication plan means, for the large company, days and days of lost productivity because Average Joes are suddenly not worrying about shipping product, they’re wondering if they should be looking for a job.

Average Joe Advice: Fact of the matter is, your boss is probably fairly well informed and he/she is speaking the truth as best he/she can. Every other piece of data that ends up on your plate should be suspect even if it’s from a credible friend. They might be trying to be helpful by telling you, but who knows where they got their data? (See Rule #2: “The Grapevine”)

RULE #2: “The Grapevine” or People hear news in terms of what they want or People are really, really paranoid

A major contributor to the rumor chaos around reorgs is the grapevine. Simply put, information that starts out as fact slowly becomes more and more rumor with each transition from one person to another. Let’s watch:

VP of Engineering to Her Staff: “They’re building a new hardware group under Ted. It’s not clear where they’ll be getting the headcount. One option would be to sacrifice headcount in other groups.” (What happen: VP stated the facts where she could, trying to give her staff a heads up)

Manager of Engineer to His Staff: “Ted has a new group. We’re liable to lose a headcount in our group.” (What happen: He starts with the facts and then follows up with a strong opinion, he’s losing a headcount. Why is he saying this? Maybe he’s been with the company for years and knows that when his boss hints at something, it’s going to happen.. who knows. The rumor mill is now officially in effect.)

Sr. Engineer to His Friend: “We’re losing headcount and it’s going to Ted’s new group. Gosh, I hate Ted.” (What happen: What was fact is now full fledged rumor ready for rapid consumption into the grapevine. YAY!)

This is simple example, but it illustrates basic human nature. We want to know what’s hell is going on and when we don’t, we’re likely to make stuff up which gives the impression we do.

Average Joe Advice: Once the rumors start flowing in your particular reorg, some pretty radical stuff is going to cross your desk. I guarantee you that while much of the tidbits are crap, there are likely gems of truth in each piece of information. I advise a journalistic policy here where you confirm tidbits of information with independent sources before you start pulling your hair out.

RULE #3: Reorgs are never going to feel like they’re over (and they’re not)

The time from when you hear about a reorg to when it’s actually executed is going to be four times as long as you think. Reorgs take forever. Plans are designed, confirmed with stakeholders, adjusted with feedback, run up the flagpole with the Big Boss, and then taken back to the drawing board. All the while this “official” process is going on, there are hallway shenanigans going on as individual political players are jockeying for headcount. All of this information is informally inserted to this process, forcing even more iteration.

Average Joe Advice: My advice here is pretty simple. Reorgs take a long time and create a lot of noise. You can either choose to become a fanboy of the reorg and pay attention to every little detail or you can do what you were hired to do, work. If you choose the fanboy route, I suggest a regimen of active listening and aggressive hallway conversation acquisition.

If you’d prefer to ignore the reorg, I recommending sitting backing in your chair and enjoying the scurrying about. Take comfort in the fact that you’re still employed and, hey, if the reorg affects you, maybe a change of scenery is going to do you some good. Don’t forget to ask for a window in your new office.

Incidentally, this is where my boss blew it. By telling me, “I didn’t want to jerk you around” and “it’s all settled”, I realized he was reasonably new to the whole reorg process. In the case of my company, the reorg had just begun a few days before and I knew, given the size of the company, we were due for, at least, two to three more weeks of organization churn. (Note: I started this article the day the boss delivered the news, it’s been two weeks since then and the buzz has not yet stopped).

RULE #3.1: Most folks actually love reorgs (but hate to admin it)

This is tightly related to Rule #4. Reorganizations represent opportunity to those who are unhappy with the state of the current organization. As mentioned above, the moment organization stakeholders hear there is a reorg brewing, they start working the grapevine to steer the course of the reorg in their favor. When you combine this fact with people’s love of gossip, you’re guaranteed a big juicy, drawn-out reorganization.

While you, the Average Joe, may be annoyed by all the hallway conversations and closed door meetings, the fact is, most folks love this shit. Who is getting moved? Really? Wow. No way? He’s an idiot! That blows! Etc. etc. For some reason, conversations about reorgs sound a lot like conversations about infidelity.

The group responsible for generating the most noise around reorgs, ironically, is the group who has the least affect on their eventual outcome, the Average Joes. These are the people who are lingering in the dark while the management team wades through strategy, political agenda, and fiscal responsibility looking for a plan which gets the company out of wondering who works for who and starts worrying about building product again.

# March 14, 2003 : Twitter : Comments (5)
Management

Delivering Big/Bad News

As a manager, at some point, you’re going to have to delivery news that is going to be of significant consequence to your employees. It’s likely to either be big news (“the team has been split into three and everyone you know is no longer on your team”) or it’s going to be bad (“we need to put you on a performance plan”).

There is probably a lot to say about how to do this well, but I want to focus on the single biggest mistake I’ve made when doing this… not giving the person time to think.

Traditionally, big/bad news is something you sit on for some time either because you have to (i.e. the timed execution of layoffs) or because you’re not looking forward to saying whatever it is you need to say (i.e. performance plans). Regardless, you’re probably going to have the big/bad news percolating through your brain for many days before you deliver it. You get comfortable with the news in that time, it becomes second nature, and less big/bad.

Fast forward to the time when you need to deliver the news to the team. In your one on one, you carefully explain the ins and outs of the situation, you summarize, and you’re done. Whew. That was easy… I thought that was going to be hard. Next topic!

Here’s what happened in the head of your employee on the other end of the table…

“Boy, the Boss is about to say something big, he/she is really nervous.”

“Ok, Boss, cut the chase, how is this going to affect me?”

“… I’m laid off? Wuh?”

Fact is, you kept on talking after you delivered the punch line (laid off, reorged, whatever), but your employee stopped listening at the punch line. They did not hear all your fabulous rationalization about the big/bad news that came after the punch line because they’re basically not sitting in your office, they’re wandering around the inside of the head trying to do all the metal digestion that you did in a week in mere ten minutes… with you yammering away about trivial details.

When it comes to the end of the big talk, you’re going to feel pretty good because when you ask, “Any questions?” you get a blank stare and no response. You will confuse silence for understanding because you didn’t want to deliver the big/bad news in the first place and just want to move on.

Problem is, come the next day, the employees are going to have had actual time to think and they’re going to be stacked three deep outside of your office with comebacks to your punch line that you never thought of.

The fix here is simple. Give them the time to think. When delivering momentous news, tell them that you’re not expecting them to react right now and you prefer if they took the day to digest and come back to have a real conversation the next day.

When you can give your team time to think about the big/bad news, you take the pressure off them when you deliver the punch line. My usual mode of operation is to preface that I’m about to deliver the news, explain I’ll answer any questions they have, but that I’ve already scheduled time on the following day to have the real conversation. I, then, deliver the punch line.

Sometimes there are immediate questions; sometimes there is painful silence. Regardless, come the next working day, they’re full of opinion.

This advice works for most big/bad news except for layoffs when someone is delivered the one-two punch of “you’re laid off” plus “get the hell out”. I’m convinced this intensely blunt way of dealing with people in layoffs is one the reasons employees get pissed and do destructive things during layoffs… they have no means of digest the news in a constructive way. They’re just gone without time to understand what actually happened.

# March 9, 2003 : Twitter : Comments (7)
Management

Synchronicity

I build software for a living. I started out in quality assurance in the 80s and now I’m responsible for a reasonably large engineering organization tasked with developing four very different products. This week, the team sat down with the executives at the company and basically asked for several million dollars to finance the development of out product.

They said yes.

I’m assuming the process is similar at various large-ish companies. The engineering and marketing teams put together the goals for the next release, they throw together some designs and some pretty slides, and then take the dog and pony show to the execs who nod a lot, ask a few questions, but ultimately trust the team to do what is best.

Sounds easy, right? Want to know the hardest part? It’s not finding good workers, thinking up innovative ideas, or even the laborious bureaucracy? it’s simple communication.

Before I explain, let me first confess that my prior gig was a start-up. Getting product approval involved getting the CEO, the CFO, the VP of Marketing, and myself in the same room for half-a-day and, viola, we had a one year product roadmap. I am used to having complete access to the decision makers, so big company development processes is terra incognito for me. The good news is that I’m pretty much done with a full design cycle and they only big surprise was how much confusion (and subsequent extra work) was caused by a single poorly defined word.

The product in question is mostly irrelevant, but one thing that is does involves file synchronization. For those of you who aren’t computer science majors, file synchronization is really, really hard. The basic idea is trivial: I’ve got one version of a file on my portable or PDA and another version on a server/desktop. File synch tools attempt to compare the two file, determine which is newer, and copy the newest version to the right place. (I.e. if the server is new, we copy to the portable device and vice versa).

Simple, right? Just compare file modification dates and you’re ready to go. What if BOTH files have been modified in BOTH locations? By different people? Yuck. File synchronization goes from being a mouthful to being darned near impossible depending on what you ask of it. It doesn’t help that it turns out that most people don’t have a clue what it means.

In order to get my product built, I had to present to five different groups of people. There was my immediate team of engineers, my product managers, my marketing folks, my senior management, and the executive management. My presentation had a good statement of direction, some slick architectural slides, and an aggressive schedule. I included a bunch of statements by customers who claimed our product would solve all their problems? I thought I was very well prepared.

The problem was I did not define synchronization in terms of the product I am planning on building and not a single person asked. This meant that everyone who walked out my presentation had their own personal definition of what synchronization meant. Some thought it was just backing up files, others thought it was the basic single user case I described above, while others thought it was the sophisticated multi-user case. No one, except me, really knew how we were tackling synchronization.

Here’s what happened. People from the engineering meeting met with people from the marketing meeting and the marketing folks said, “Hey, did you hear about the cool product Rands team is building? It does multi-user full file synchronization!” The engineer types — who had the best idea of what we were planning — would look at the marketing types like they were crazy, “No he’s not, he’s doing the simple case because the multi-user case is damned near impossible.” “WHAT?! That’s not what he said in his presentation! We can’t market simple synchronization!”

And so on…

By the time I got to the executive review, the hub-bub about the synchronization vagaries had bubbled up to various VPs along with the usual grapevine signal to noise degradation. The rumor that my head was deeply implanted in my ass regarding this particular product was firmly entrenched in various powerful brains which meant I got asked some fairly tough questions mostly in the realm of, can you guess, synchronization.

Fortunately, I actually knew what we were doing with regarding to synchronization and that we would be developing a compelling product with that strategy. When it became clear to everyone else that I had a clue, they recommended that I circle back with the various product fiefdoms to “make sure everyone is goal aligned”. What should have been five meetings turned into ten and that doesn’t include the time reworking multiple presentations and specifications to carefully describe our synchronization strategy.

It’s easy to blame the word synchronization in this story because it’s so ripe for misinterpretation, but that is not really the point. Big companies are big because THEY HAVE LOTS AND LOTS OF PEOPLE. In my prior start-up life, the synchronization confusion would have never had a chance to grow out of control because I saw everyone responsible for getting product out the door every single day. Hallway conversation does wonders to contain viral rumors.

I’d like to give some good advice here to others facing large company communication problems, but so much depends on what you’re trying to trying build, who you need to ask permission of, and what’s the relative aptitude of those influencers and decision makers.

Perhaps the best advice is to carefully look for those blank stares when you’re presenting especially if it’s on the face of your VP of Engineering. Blank stares indicate confusion and confusion means more meetings.

# February 14, 2003 : Twitter : Comments (2)
Management

Engineering Management Interview Questions

A former employee recently asked, “What are questions you ask software engineering management candidates?”

These questions really focus on the people-skills for managers. If you’re looking for technical questions, I highly recommend techInterview or stumbling around on Stack Overflow.

Lead Off Questions:

These are vanilla, boring questions which I use to begin to assess a candidate. I usually base follow-up questions on the answers to these questions. One word or short answers to any of these questions, in my opinion, are significant red flags.

Follow-up Advanced:

Here we start to get into some meat. We’re looking for meaty answers here:

Follow-up Even More Advanced:

The serious meat. Tough questions which reveal much about the management style of individuals:

# October 14, 2002 : Twitter : Comments (7)
Management

IF YOU SEE A SNAKE...

Jim Barksdale of Netscape fame offers us these management nuggets:

If you see a snake, kill it.
Don’t play with dead snakes.
Don’t forget that great opporunities look like snakes at first.

# August 17, 2002 : Twitter : Comments (6)
Management

SURREAL MEETINGS

At the new gig, everyone is sporting fancy laptops and the whole building is wired for 802.11b. This has some significant implications on the way work gets done in a meeting.

First, let’s describe the average well-run product development meeting in a non-wireless setting.

A bunch of folks show up. The alpha person has provided an agenda beforehand and each person has read that agenda and determined what they need to know/bring to the meeting. It’s likely if they needed to bring something, they printed it out or forwarded to the rest of the team so they could print it out.

The meeting begins. The agenda is followed. Brainstorming occurs and action items are assigned for questions which are asked, but can not be easily or honestly answered. Print-outs are examined; more action items are assigned because of additional unanswerable questions. The meeting completes, actions items are pondered, print-outs are thrown away, and the cycle repeats itself.

Now, add wireless and let’s see what happens.

An agenda is sent out, but the amount of preparation which occurs less because you know, going into that meeting, you’re bringing your entire desktop to the meeting in the form of your wireless notebook. What else do you need? Why print out what you have?

The meeting begins. The agenda is followed. Brainstorming occurs, but there is decrease of action items because you are able to dynamically problem solve. Wondering about the status of that bug? Well, fire up your bug system and take a real time look. Forget to forward your slide set to the team? Mail it now. Save a tree. The meeting finishes and there is a distinct lack of action items because most questions were answered. Folks leave the meeting and silent ask themselves, “Why do we have that meeting?”

Now, I’ve described a semi-fairy-tale-like scenario above and the reality is a bit bleaker. Wireless-equipped meetings do feel more productive because of the presence of much data, but that data can be a distraction because not only do have access to bug databases, project schedules, but also PORN AND INSTANT MESSAGING WOOOOOOOOOOOOO.

These distractions lead to a lot of people typing away during meetings and the impression that they aren’t actually paying much attention. Sure, they might be digging up a specification because they know it’s required reading come the next agenda topic, but they also might be checking their stock portfolio. Who knows.

My impression is that wireless access etiquette will evolve at a company. There will be meetings were access will be required (where timely access information is essential) and meetings where it will be forbidden (where focused, creative thinking is valued).

Whether it’s a cell phone in your car or a wireless notebook in a meeting, the argument is not whether it’s a good thing, it’s a question of how much of your brain you want to do the devote at the task at hand.

# August 4, 2002 : Twitter : Comments (4)
Management

ACRONYMS, ABBREVIATIONS, AND BUZZ

I’ve been browsing Dive Into Mark’s “30 Days to a More Accessible Weblog” and came across a great intellectual exercise.

His Day #17 entry “Defining Acronyms” listed 51 acronyms and abbreviations that he’d recently used. They were:

ADA, ALT, AOL, API, CGI, CMS, CSS, CTRL, DMV, DNS, DTD, EFF, FAQ, FSF, GFDL, GIA, GPL, HTML, IE, IIRC, IIS, IO, KB, KDE, LONGDESC, MB, MSDN, MSN, MT, Mac, NC, OPML, P2P, PGDN, PGUP, PBS, PDF, PONUR, RSS, RU, SOAP, SSN, TDD, US, VNC, W3C, WCAG, WYSIWYG, Win, XHTML, XML.

(Yes, I know he says there are 50… there are 51… I can count… Mark can’t.)

The exercise was this: Given this rather tech-centric list, how do they various acronym look-up sites do? I picked three sites: Google, Acronym Finder, and Acronym Search. I made up the rule that I would give the site a point for a correct definition if the acronym showed up on the first result page.

Acronym Finder: 90%
Google Glossary: 71%
Acronym Search: 73%

Random observations:

- This is not really an apple to apple comparison. I’m assuming that Google is building the glossary list based on their crawls of the web whereas the other two sites specialize in this sort of thing and accept submissions to improve their data set. This is a back handed compliment to Google since without really specializing in acronyms, they fared pretty good against a specialized site.

- Nobody knew what GFDL stood for - according to Mark it stands for GNU Free Documentation License. Strangely enough, the Google front page point straight to the thing which is odd. Knowing nothing about how Google creates it’s glossary, I would’ve assumed they would’ve mined popular search results for acronyms.

- Nobody knew what IO stood for, either… including myself. A regular Google search didn’t find Mark’s definition either “Instant Outlining”. This observation makes a valuable point regarding acronyms. They usually start at as time saver for some collection of people who ARE REALLY TIRED OF TYPING INTERNATIONALIZATION AND WOULD PREFER TO TYPE I18N. Problem is, the context which makes the word meaningful doesn’t travel around with the world with it, so you end up needing glossaries or acronym finders. I still don’t know what Instant Outlining is, but it’s probably important to Mark and his clan. (Note: this probably applies to other unknowables such as PONUR)

- Here’s the list of words Acronym Finder knew that Google did not: ADA, CMS, OPML, PGDN, PGUP, RU, VNC, WCAG (wow), and Win (probably too common of word). Yes, some of these words are abbreviations and not acronym. SAME DIFFERENCE IN MY BOOK.

- Acronym Search didn’t know what XHTML stood for. That’s our dumbshit award for the contest.

Why all this energy regarding acronyms, Rands? Well, it’s not really acronyms that I’m concerned about, it’s glossaries. Being in high tech, I’m inundated with a steady stream of acronyms, abbreviations and buzzwords. We geeks love to create them because we essentially like to build stuff and IT AIN’T REAL STUFF UNTIL IT’S GOT A GOOD ACRONYM OR CODE NAME.

Unfortunately, these words confuse people. They lack context until they reach critical mass and that means corporations are ultimately losing money because they’re people aren’t able to talk to each other. PLEASE GET THE P39 QA’ED ASAP BEFORE ROGER LANDS HIS XHTML BRANCH OR WE’LL ALL BE SOL.

I’m sure many companies already do this, but I’d recommend that any largish project should have an accompanying glossary of terms. This is living document which draws the lines between the buzzwords and the content. Yes, it will take extra time to generate this document and, yes, it will always be out-of-date, but some data is better than none.

(ps. oh yeah, Mark’s idea to use the acronym tag is a good one. Do it.)

# July 14, 2002 : Twitter : Comments (0)
Management Splitsville

Your Resignation/Layoff Checklist

I’m switching jobs over the course of the next week. Been with the current gig for about four years and the stench of idiocy was getting terribly strong, so… Splitsville.

A STATE OF THE JOB MARKET ASIDE: I realize it’s a tough economy right now, but I really had no problem finding a new job in the Silicon Valley.

During the course of one month, I got enough traction for a variety of different gigs to say that, for technical management, there is no reason you shouldn’t be able to find a job if you keep the scope of what you want to do broad enough. I’M REALLY SORRY IF YOU’VE BEEN UNEMPLOYED A LONG TIME AND WANT TO YELL AT SOMEONE.

Here are the beginnings of a checklist of things you want to do your last week on the job.

DON’T PROMISE WHAT YOU CAN’T DO: If you’re resigning, you’ll be tempted to over commit on deliverables before you leave. This is guilt talking. You feel bad for resigning and are trying to make up for the fact that you might people leaving in the lurch. Remember that no matter how hard you try, you will become useless in your final days.

PRACTICAL EXPERIENCE: I totally blew this in past resignations. YES I’LL REWRITE THE IMPORT/EXPORT ENGINE IN TWO WEEKS NO PROBLEM ANYTHING ELSE? I purposely skimped on the deliverables and also completed whatever I committed to with a week to spare because, face it, my engagement level in that last week was minimal.

RESPECT YOUR NETWORK: There are, at least, three people you’ll need to make sure are aware you want to stay in touch with them. I don’t know who these people are because I don’t know who you are or what you do. If you’re looking for a way to identify these people, pick the people that you respect or maybe pick the people you hang out with outside of work. Or both.

No matter where you are in your career, you need to continually develop your network of people because it’s very likely that one of those three people will assist in future employment/opportunity. Personally, I’ve been in high tech for over ten years and every single job I’ve got has either a direct or indirect result of knowing someone from a prior job. You’ll hear the phrase, it’s a small valley. It is.

PRACTICAL EXPERIENCE: This was easy. Every manager reporting to me, the CEO, and the Director of User Interface. Helped that these were all drinking buddies.

DON’T TAKE CHEAP SHOTS: If you aren’t leaving under the best of terms, you’ll be tempted to send out the scathing email which “sets things right”. This is stupid on many levels. It will negate any positive work you did while you were with the company. Also, you’ll hurt your network because everyone (including those who know that you aren’t insane) will remember you as that freak that yelled in email and didn’t bother to spell check.

Remember, you are leaving and the people you consider to be the problem are staying. It’s not your problem anymore, don’t waste your energy.

PRACTICAL EXPERIENCE: We had a B- QA engineer at the company who got passed over for a promotion and decided to bail in style. On the last day of his employment, he sent a grammatically painful email which went through his organization, person by person, and hammered them. His incoherent rambling is still posted on some cube walls for its comedic value and no one has a clue that he actually wrote decent test plans.

DO RIGHT BY THOSE WHO WORK FOR YOU & WITH YOU: If you happen to be in a management position, the previous two comments apply to you in triplicate. You’re not allowed to fall prey to the dreaded “short timers’ disease” because you are acting like a leader and representing the company until the second you are out the door. If this doesn’t make sense to you then it’s likely you weren’t supposed to be a manager in the first place.

PRACTICAL EXPERIENCE: I’d give myself a solid B in this category. I’ve definitely succumbed to short timers’ disease in the form of daily 4pm exits, but I also decided to give written reviews to all my direct reports in my last two weeks. WELL WRITTEN REVIEWS ARE PAINFUL AND TIME CONSUMING. I was surprised when I handed the final reviews off to our HR and my HR rep said that no other manager had taken the time to do so. HELL YES.

Getting out the door at any job is always a tough proposition. You either want to go and rapidly realize that everything you do in the old job is useless or you’re laid off and you want to punch someone repeatedly. In either case, it’s important to remember that you’re not the only person going to through significant change. The people you’re leaving behind will likely be similarly dazed. Going out in a profane blaze of glory will leave an indelible impression on their confused minds. Is that how you want them to remember you?

# June 29, 2002 : Twitter : Comments (4)
Management

THE BIG QA FREAK OUT

Mondays in the software biz are hell. Because productivity decreases in relation to how you close you are to Friday, Mondays, invariably, are full of everyone’s guilt to actually catch up on all the crap they ignored during the end of the week.

This Monday’s freak out was courtesy of my QA (“Quality Assurance”) lead. I heard her simmering in the hallways all morning. She was talking in hushed tones to a variety of people, building up her freak out just for me. I quickly escaped to an offsite lunch, but was immediately leapt upon when I walked into the office…

“Rands, can we talk for a minute?”

Shit.

We walked into the closest conference room; I gripped the table and braced myself.

“DEAR LORD WE’RE GOING TO SHIP HORRIBLE PRODUCT AND YOU’RE SETTING UNREALISTIC DEADLINES AND QA ALWAYS GETS THE SHAFT AND DO WE SUPPORT INTERNET EXPLORER 4.0 AND MY CREDIBILITY IS ON THE LINE HERE AND JESUS CHRIST DIDN’T WE LEARN OUR LESSON LAST TIME CHRIST GOD I HATE HTML AND THIS DEVELOPER KEEPS ON DIDDLING WITH SHIT.”

Rands Rules o’ Software Management #1: If someone is going to freak out, it’s going to be on a Monday.

When you witness a freak out, it’s important to quickly assess whether or not it’s a Monday or not. You also need to follow a couple of easy rules:

Don’t participate in the freak out.

This can be difficult because, hey, it is Monday and you did take last Friday off to play disc golf and smoke dope, oh my god, this person freaking out in my cube is ABSOLUTELY RIGHT AND LET’S GO TO THE CEO AND MAKE THIS RIGHT. Trust me, the CEO is much more adept at identifying freak outs than you and if you show up on his/her desktop blithering and throwing dry erase markers, you’re losing valuable respect points by the moment.

A less obvious participation maneuver is to make an important decision based on data acquired from a freak out. Remember, this data has been tainted by Monday and if you don’t wait to Wednesday to see what actually is going on, you’re an accessory to the crime.

Learn to recognize common freak outs.

Every person in the organization has their button which, when pushed, will result in a freak out. It varies in content and volume, but they always exist. Your job as a manager of people is to quickly discern where these buttons are and predict freak outs before they occur.

As was my case, I’d been expecting my QA freak out for over a week. Every software project I’ve worked on has had one as soon as someone with authority starts getting tense about dates. WAIT YOU MEAN WE HAVE TO ACTUALLY DO WHAT WE SAID WE’RE GOING TO DO? FUCK THAT.

Give the freak the benefit of the doubt.

Chances are your freak really does have something to say, they’re just under the influence of Monday. They probably drink too much coffee, as well. It’s important to try to determine what the person has to say although it might be easier to discern come Wednesday. Even if you can’t sift through the noise, the act of doing so might calm the freak a bit.

Hammer the freaks with questions, present them with facts.

Ultimately, a freak out is about the desire to be heard. Properly timed and correctly constructed questions will lead your freak down a road where he/she may find their own answer. If questions aren’t working and you’ve predicted this freak out then hammer the freak with readily accessible facts.

As with the case with my QA freak out, I had a good two hours in the morning to sniff the prevailing winds which meant I leapt into our bug tracking system to figure out how many bugs this person had filed, what were their severity, as well as other juicy tidbits.

When the freak out began, I started asking leading questions, “How do you know this?” “What facts do you have to support this opinion?” When it became apparent that the QA person was working from an emotional state rather than a logical one, they began to calm down. Thus begins the cooling period.

Get the freaks to solve their own problem.

If you’re lucky and your freak has half-a-brain, they probably already have a solution to the problem in mind. This is good news for you because it means all you have to do is listen to yelling for a good fifteen minutes while the freak wears out. After that, a few well designed questions will reveal a suitable answer and you’ll look like a hero for sitting there and nodding.

WARNING: The worst type of freak out is one which is purely emotional, non-logical, and based on little to no fact. It also lacks any type of solution because there really isn’t any problem except that this person really needs to freak out. The volume in this type of freak out can be negatively intoxicating and you’ll be tempted to jump on the freak out band wagon. Don’t. The best move here is to simply listen and maintain eye contact. Your calmness is a primal attempt to telepathically reflect the insanity back to the freak so they will realize they’ve gone off the deep end.

In ten years of software development, I’ve discovered that most freak outs are a symptom of a larger communication problem in the organization. The information your freak needs readily exists somewhere, but, for some reason, they lack the network of resources to find it. Fortunately for them, they have you, the manager who got to where you are because of your superior network of resources and information. The question, why did they have to freak out to get access to it?

# June 17, 2002 : Twitter : Comments (3)
Management

No Title

Last night a colleague mentioned there are two ways to motivate a team:

This is true. These are definitely ways to get the troops in line. In fact, after two glasses of red wine, I was staring at these two options thinking, "This might solve my hard problem." My hard problem is that Fridays have died at THE COMPANY. I’ll explain.

TWICE THE HEADFirst, the CEO telecommutes from Chicago and is not here on Fridays as he’s on his way back to Chicago. The trickle down effect means that our VP of SALES isn’t here either. The precedent which is now set essentially gives ANYONE in the company the right to "work at home" on Friday.

The ability to actually work while working at home is a rare one. I’ve tried it. Doesn’t work. Too many toys at home to distract me. I’ve watched others try it, too… doesn’t work for them for a variety of reasons. There are people who are very good at working at home, but these tend to be the HYPERFOCUSABLE types who are also great assembly programmers.

Back to Fridays. The added benefit of these "work at home" Fridays is that the folks who actually make it in are distinctly aware of the folks who aren’t there which means they’re liable to slack or leave early. My rough estimate is that we’re losing roughly 20% of our productivity because Fridays have died.

Unacceptable.

Dead Fridays are truly only a symptom of a larger problem. THE COMPANY, like many small-ish start-ups who’ve made it this far, is basically waiting for other big companies to start buying software again. Few, if any, sales are coming in, so THE COMPANY has focused on getting the expenses under control, going through three layoffs, scrambling to get additional funding, and… waiting.

At the end of this waiting period there are two options. Either, become successful or die. I would argue the death of Fridays is a preliminary indication that others believe the die scenario is inevitable which means that the problem which actually needs to be solved is "belief that THE COMPANY will be successful".

If this is true, neither of the strategies above will work because both assume that an employee has something he/she is a) willing to work hard for (ie: unreasonable deadlines) or b) willing to defend (ie: against a mortal enemy).

# April 6, 2002 : Twitter : Comments (0)
Management

First Entry

A friend asked why I didn’t have a weblog to which I replied the following,

… a few thoughts:

o In general, weblogs annoy me because folks haven’t spent the time to actually construct a coherent thought. They’re rambling… and rambling is good, but it’s generally an activity which occurs inside ones head. Rambling to OTHER people is generally received as "Uh, what are you talking about?"

o IT IS VERY LIKELY because of my predisposition towards weblogs that I am unfairly biased. Meaning, there are probably many worth weblogs out there, but since I found the first, say, 10 annoying, trite, and/or dull, I stopped listening.

o I LOVE TO WRITE. REALLY I DO. IF YOU DON’T WRITE IT DOWN IT NEVER HAPPENED.

And then I asked her some questions. And then I said,

“WITH ALL THAT SAID, I’ll start a weblog tonight. CALL IT A SOCIAL EXPERIMENT

The primary reason this is an experiment is because I’m using the JERKCITY brand as part of this weblog. This means folks are expecting me to go HGUAHGUAHGUBLBHAUGHUAH which I’m not currently planning to do.

My gut feeling is that a weblog is a CRY FOR ATTENTION and I get plenty of attention. People are walking into my office on a minutely basis asking, "Rands, solve hard problem X". And I do. I get to solve hard problems. My brain is engaged so there isn’t much excess energy to devote to a weblog, but YET HERE WE ARE.

Perhaps there is another reason for weblog. Perhaps a reasonably well thought out weblog will PREVENT aforementioned folks from ENTERING your office in the first place because you’ve already thrown the answer (whatever that answer might be) out into the world via the Internet.

This thought is a really restating point #3 above - "IF YOU DON’T WRITE IT DOWN, IT NEVER HAPPENED."

I buy that. I like that. Here’s another reason why writing it down will make you appear smarter than you actually are…

Rands explains how to solve hard problems

Hard problems are best solved by:

1) Thinking about the problem 2) Talking about the problem with others. This is the process I will call "cross pollination" or "hallway conversations". The goal of this phase to first acknowledge that you aren’t the smartest person on the planet and that others might be able to add value to your analysis of the problem. 3) Forget about the problem. You’re not actually NOT forgetting about it because your brain doesn’t let go of hard problems until some type of solution/resolution is reached, so we’ll call this "background processing". Sleep is a good way to do this and has the added benefit of decreasing emotional involvement with the problem.
4) Arriving at a solution. The beloved A-HA! moment. Pure synthesis. It rocks. 5) Writing the solution down. Writing it down is essential because, until this point, it’s very likely all you’ve done is think and talk about the problem. Writing it down forces you to arrange the solution (and possibly the problem) into linear steps. This act may reveal interesting aspects to the information that you couldn’t grasp when you were running around the building yelling at people about the problem. It also creates a document of your solution which means if you’re hit by a bus after you’ve come upon a cure for cancer that someone else can claim your work as their own and receive the Nobel Prize.
6) Repeat steps 1 thru 4 replacing PROBLEM with SOLUTION. This is error correction. Did you capture all the various intricacies of your solution when you wrote it down? How about that off-the-cuff conversation you had with SOandSO over a donut? Better make sure.
7) Executing the solution. Translation: FAME/GLORY/SATISFACTION/DINERO. It’s important to note that it’s difficult to execute this step if your solution blows. Alas, this is why this section is called HOW TO SOLVE HARD PROBLEMS and not HOW TO SOLVE HARD PROBLEMS WELL.

In any event, DO THIS FOR ME. When you have a hard problem, please bring me in at STEP #2. Thank you.

Hey, this weblog gig RULES.

Rands explains the deal with ALL CAPS

Because of Jerkcity’s NET_FAME, I’m granted a special dispensation when wandering around the IRC (NOTE TO FANS: #jerkcity is on #EFNET - IF YOU SEND ME MAIL WHAT #EFNET IS, I WILL IGNORE YOU - PROMISE). Translation: When I show up and starting RAMBLING IN ALL CAPS, most folks don’t immediately BOOT’n’BAN because they realize it’s MY JOB… usually.

Usually when I arrive in a channel and starting BLATHERING IN ALL CAPS, someone invariably asks, "What’s with the ALL CAPS"

ALL CAPS is generally viewed as yelling. Has been for as long as I’ve used a computer. (HINT: BBSes) What you should see when RANDS when shows up in his IRC guise and is speaking in ALL CAPS is that he is not really shouting… he’s using all caps to indicate sarcasm… stupidity… ignorance. These are tones which we easily discern when we’re 1:1, but we’re not right now, are we? I’m sitting here at my desk drinking SportTEA and YOU’RE SITTING HERE WONDERING HOW A GOOGLE SEARCH FOR ADMIRAL KRAG PORN ENDED UP WITH YOU READING JERKCITY.

The point is, yelling is reasonably easy to indicate with a keyboard. There’s a even a key for it — it’s called an exclamation point.

"You suck dick!"

What typographic means do we have to indicate sarcasm? A smiley? That’s way gay. I claim that caps is the solution. It’s elegant and you don’t have to remember WHICH PARENTHESIS TO USE.

MARISA TOMEI SUCKS DICK.

Now, Marisa doesn’t really suck dick or maybe she does… that’s not the point… the point is, compare the ALL CAPS version to the HONEST AND TRUTHFUL version.

Marisa Tomei sucks dick.

HOLY SHIT? SHE DOES? LORD GOD HEADING TO HOLLYWOOD/THE OSCARS FOR STARSTUDDED BLOWJOBS.

# April 4, 2002 : Twitter : Comments (0)

Popular

To understand nerds, you simply need The Handbook.

If you lead people, remember that Bored People Quit.

Bright ideas need the FriendDA.

You have 30 seconds to make an impression with your resume.

Stop reading right now. Look at your desktop. How many tasks are you working on besides reading this weblog? A lot? You've got N.A.D.D.

More

The Books

Being Geek CoverManaging Humans Cover

 

ADS BY FUSION

 

 

The Shirt

Rands Shirt 3

 

HOSTING BY

(mt) logo

 

Categories

 

Diversions

 

RANDS LTD.

 

Search