Voice is destiny

Everyday, Pandora offers me songs I've never heard before, songs that are similar to the ones I have registered.  Some of the suggestions I like, some I don't.

Many of the songs I like have hard rock roots, like The Smashing Pumpkins.  Eventually, Pandora will a song that fits in the same category, except for one very specific trait: the voice will be deep and "monster-like".  Think Metallica.  As soon as I hear a voice like that, I thumbs-down the song. 

Think about the difference between Metallica and bands like the Pumpkins.  You could argue that both have a lot of talent.  Both do a lot yelling.  But the Pumpkins yell in a relatively higher pitch, while Metallica uses the monster voice. 

Even if everything else was equal, that small difference would make all the difference.  I suspect people who like metal are attracted to the low, powerful, almost threatening voice metal bands often use. 

This is a long way of getting to discussing one's voice at work.

We frequently have discussions with users and business managers about deadlines that need to be met, deliverables that disappointed, features needed yesterday.  Your voice will make a big difference in how the conversation will turn out.

Occasionally, a powerful, threatening voice might work, but usually, you want to cultivate teamwork and mutual empathy.  Soften your voice, and try to persuade, not control.

And, as a side note, smile as much as possible, in direct proportion to how much trouble your message might stir up.  Unless you're singing in a hard rock band.

How We Decide

Imagine you have two decisions to make: one which is complex, having a lot of variables to consider, and one that is much simpler, with only a couple of variables.  An example complex decision might be choosing which car to buy, while a simple decision might be what color.

Which decision will benefit more from thinking through the options logically?

Jonah Lehrer's How We Decide instructs us to use reason for simple and new decisions, but rely on our instincts for more complex ones. 

In other words, thinking about what color will probably make sure you get the best choice (for you), but thinking and comparing the cars will likely prove futile.  The book shows us that our brains can only actively consider a few variables at once, and decisions that have more variables end up being a crap shoot and often worse because we end up over-weighting less important factors.  (Yesterday's post might be an example of the latter.) 

Even choosing which box of cereal to buy can overwhelm us.  Because most of us don't buy cars too often, if you can narrow it down to three, just getting the cheapest one probably works best.

If you deal with complex situations frequently, create frequent practice opportunities to sharpen your instincts.  Flight simulators have worked wonders for pilots.  Also, take the time to reflect later on your satisfaction with your decisions and thoroughly understand what happened -- why you succeeded or failed.  (Reminds me of deliberate practice.)

The lessons of the book are pretty straightforward.  Its real strength comes from the fascinating stories and research examples.

Its conclusions can also be useful if you flip the decision around: when you're trying to convince someone else of a decision. 

As developers and engineers, we often try to convince our customers, our audience, each other by laying out intricate arguments while highlighting caveats.  Instead, identify the top priorities and focus on those.

After you become the expert, take a stand

You don't need to be a schmoozer or extroverted center of attention to be a leader in your department. You can also just know your stuff and be willing to stand up when your issues come up.

The Ben Bernanke that emerges from this account of the height / nadir of the financial collapse provides a fascinating example. (Unfortunately requires subscription.)

When White House officials first interviewed Bernanke for the post of Fed chairman, he was so quiet they worried that he lacked, as one put it, "assertiveness."

Sounds like the wrong guy for the job, and his television appearances haven't won any glamor awards.

But later, people scoff at his idea to give $85bn to AIG.

"Do you have eighty-five billion?" Representative barney Frank asked.
"I have eight hundred billion," Bernanke said, referring to the Fed's balance sheet.

You can almost imagine him thumping his chest.

Then, he needs to convince Hank Paulson to take drastic action beyond anything being contemplated. Keep in mind that Hank Paulson is as intimidating and strong a personality as you're likely to ever meet.

"Hank! Listen to me," he interrupted. "We are done!"

It was the first time Fed officials had heard him raise his voice.

"The Fed is already doing all that it can with the powers we have," Bernanke continued. One participant recalled, "Ben gave an impassioned, linear, rigorous argument explaining the limits of our authority and the history of financial crises in the US and abroad.... It was an encyclopedic tour de force."

It was as though Bernanke were the professor and Paulson the student. Bernanke's comments lasted about fifteen minutes, and Paulson was uncharacteristically silent until near the end.

The article mostly focuses on the other names, particularly Paulson, as you'd expect. These are just a couple snippets that I pulled out.

Bernanke doesn't really have a gift for gab, nor does he seem to like attention. However, he clearly inserts himself when he has to. He takes an informed stand, defends it, and is willing to suffer the consequences should he be wrong. None of these things Bernanke proposed had ever been done before.

Obviously, none of us are dealing with issues of this magnitude. Scale it down.

What major decisions are being made in your department? Which ones should you take a strong stand, even though you're not 100% sure it will work? The margin of error in our field is surely more forgiving.

How to make great software

It's just a spreadsheet, but it's been programmed to answer, with startling accuracy, questions like, "Is Iran going to build a bomb?" and "Which financial firms will commit fraud?" It's a fascinating piece of software, but this quote underlined a critical point:

I think the model is, I’m sure, brilliant. But lots of other people are good at math. His gift is in interviewing. I’ve said that flat out to him, and he’s said, ‘Well, anyone can do interviews.’ But they can’t.”

The software's creator performs the interviews to generate the inputs for each prediction.

As developers, we often get caught thinking it's the technology, it's the algorithm, it's the technical expertise that makes or breaks our software. Sure, that's important. If that stuff didn't work, it'd be useless.

But that's not what makes it great. It's talking and listening to the users and finding out what they really want. It's understanding the domain space so well that you pull in the important variables.

Anybody can do that stuff. But, as is constantly proven, they can't.

How to say good-bye

Don't screw it up at the end. I've been thinking about this lately given all the turnover going on around me. It sounds easy, yet there seem to be a lot of ways to do it badly.

I had one boss who was extremely well liked by his business users and his own staff. He flubbed the good-byes, and that's what everyone remembered. When staff members would leave, he would frequently miss the good-bye party, and that soured their memories of him later. When he switched to a different project, he never again stepped foot near his old users -- not even to tell them that he'd been given a new project -- and they felt completely abandoned.

Another guy I worked with adamantly refused to allow or participate in any kind of farewell party or drinks for him on his way out. Obviously he didn't want the attention, but how hard is it to grant this simple request? Up until that point, we all thought he was a normal, good guy. Only someone who was pathologically self-conscious couldn't bear to stand around for an hour smiling at people, so we started wondering.

Finally, there's the old standard, whether you've been laid off or are quitting: the good-bye email. Unless you have an axe to grind AND you intend to use it, keep it simple.

The greatest example of having a serious axe is Ken Hamidi. The legal battle over his "good-bye emails" to Intel lasted 8 years. He complaints were serious and real, he refused to settle, and he ultimately won several lawsuits Intel filed against him.

Most of us just have small gripes and complaints. Keep them to yourself. Send a kind, professional email to the co-workers you liked, then leave the bad feelings at the door on your way out.

The weirdest email I ever received came recently, when two people were quitting on the same day. The first guy sent a polite, professional email. The second sent his email about a half hour later -- the same email, but with a few phrases and adjectives moved around. Apparently, he found sending a simple email so difficult he had to plagiarize someone else's!

Firing up the troops

A friend of mine works at a financial firm that had big layoffs last week. On Friday, after 4 brutal days of layoffs, the COO held a town hall with several hundred people at the corporate headquarters.

Out of that speech, here's the line that my friend remembered:

"As you know, we have a lot fewer people now, so everyone here will have to work harder and longer hours."

Message to COOs (and other executives): if that's what's in your head, better to keep your mouth shut. All the time you and your staff spent putting the powerpoint together, arranging the room and AV equipment, and assembling everyone for the town hall would be better spent focusing on business problems.

I'm sure nice words surrounded that sentence -- things like "Our people are our most valuable asset" and "Market conditions forced us to make these difficult choices" -- but none of that rings with authenticity. The bit about working harder? That sounds very real.

I doubt many people physically walked out, but I'm sure a large percentage mentally did. As soon as the market turns, those people will walk out. They're fired up all right.

A speech like that isn't communication and it isn't leadership.

Estimations and deadlines

One critical division between mid-level coders and seniors coders: willingness to set a deadline for themselves.

"When do you think you'll have that done?"

Senior developer: "Next Friday, assuming there's no surprises with the vendor feed."

Junior or mid-level developer: "Um, I don't know yet."

I understand the reluctance to give a date. I understand that unexpected problems arise. I also understand that managers often try to hold you to your date, even if it's a "wild guess."

Here's the deal though:

1. Your manager should help you create more time if you need it.
2. The more skilled you are, the better able you are to anticipate currently unknown but potential problems, and build that into your time.
3. The more skilled you are, the better able you are to articulate what potential delays might occur such that your users, fellow developers, and manager understand why you're saying the work will take two weeks instead of one.
4. The more skilled you are, the more likely you are to give deadlines that you can meet or beat most of the time.

Don't fall into the trap of believing that being clever enough to wiggle out of giving a due date is a skill that shows your experience. In fact, the opposite is true: strong developers give dates.

Job losses

A friend pointed out a verbal fight that broke out at a financial firm. The head of the division has an internal blog, on which he wrote something like "as widely reported, additional job losses will be coming in the next few weeks".

Many people commented on the blog. One person took great umbrage at the word "job losses". Her point was that losses are accidental, mistakes. Because the head of the division was directly responsible for cutting staff, and, as a senior executive, possibly involved with the strategies that led to the debacle that led to the need to cut staff, she felt he was trying to use language to wiggle out of any responsibility. (I can't help but note her "bravery," since her name was posted next to her comment.)

I do have some sympathy for the executive. I think the tone he attempted to convey was the seriousness of the situation. You might say, "I'm sorry for your loss" at a funeral, and the emotions at the firm are funereal.

On the other hand, the whole language around layoffs has gotten far too soft and annoying.

When I started my career, companies regularly called layoffs either layoffs or terminations. Laid off employees regularly stated, "I was fired." If you wanted to be doubly sure no one thought you got canned for cause, you said, "I was laid off."

Since then, execu-speak has gone wild. In the late 80s, we started calling it "downsizing" or "trimming". This parallels the time when workers stopped being people and became "human resources". Later "right-sizing" tried to replace "downsizing", but thankfully failed. Around the turn of the century, "cutting" or "reducing headcount" dominated.

The one I hate the most is "redundancies". To me, the word is a joke. Redundancies occur when two firms merge; as a result, some people are laid off. At some point in just the past few years, it became applicable to all layoffs. If a company decides to cancel a product line and lays off the 500 employees that worked on it, they'll say they had 500 redundancies. Redundancy means you had 2, so you got rid of 1. In these cases, they're left with 0.

The old words remain, but the new words become widely adopted. They seem softer and, because they're impersonal, you can say them without feeling insensitive. And, I do believe that much of their appeal comes from the fact that it indicates that the executive who makes the decision had no responsibility in the matter.

The woman's real message is: if you're going to fire people, own up to it. Hear, hear! Being so wiggly about it can be, in itself, a form of insensitivity.

Who's fault is it?

Ever had a good idea? Maybe something simple, like changing the color palette of the app to shades of blue. You brought it to the team, they mostly ignored you.

Later, it turns out, you were right. The users hated the existing color palette. Responses indicate blue would have been best.

Who's fault is it?

In an ideal world, we wouldn't ask this question. Instead, we would move on to "what do we do now that we're in the situation we're in?"

But, usually the person asking this question is the person who suggested the blue colors. "Those idiots should have listened to me. It's all their fault the app looks hideous. I told them to change it to blue."

How hard did you push to change it to blue, though? Mentioned it once?

Often, you have to push an idea several times before people stop and hear you. More importantly, you have to be able to express why blue would look better or appeal to customers. If you can't do these things, then people would have to follow your idea slavishly -- hardly a good idea. If you didn't do these things, then it wasn't really an idea that you were willing to bet on.

A parallel would be the guy who says he knew a month ago Citi shares were going to drop to $1. How many shares did he short? Zero. People would pay millions for accurate advice like that. He could have quit his job, instead of working for peanuts. But he knew.

If you have an idea, you need to put your money down, put your reputation on the line. Otherwise, it's just words.

Many successful projects of all sizes -- Google Reader, Facebook, open source, to name some software examples -- faced strong opposition. They got done only because someone believed enough in it to put their reputation on the line, and communicated the brilliance of the idea convincingly.

Coding epistemology

Jeff Atwood has a nice post about knowledge -- specifically, one way to learn something well.

I consider there to be the three levels of knowledge. They reflect my belief that knowledge needs to be shared to get the most value out of it.

1. knowledge you know. You read something, someone tells you, or you do it yourself, to the point where now you know it. But how do you know you know it?

2. knowledge you can explain to someone else. This requires you to organize the information. Many times, in the actual moment of explaining, you will suddenly realize a gap in your knowledge or a fallacy in your logic. I think this is akin to getting a call from your mom that she's coming over, and realizing only at that moment that your apartment is a mess; you're viewing yourself through someone else's eyes. And yes, the act has to involve explaining and a someone else, not just a mental exercise where you convince yourself that it could be done.

3. knowledge you can answer questions with. People react to your explanations in unpredictable ways; weird questions pop out. They try to apply it to things you'd never think of on your own, just as end users do things with your application that you'd never considered. These questions test the robustness and flexibility of your knowledge -- or, said another way, they test whether your understanding is at the implementation or the abstraction level.

You are more likely to succeed at numbers 2 and 3 if, as in Jeff's example, you wrote something yourself from scratch, as opposed to someone just explaining it to you once. Someone explains something to us, we can walk away with a false sense of security in our knowledge, which easily crumbles in the face of simple questions.

Implicit in number 3 is the possibility that someone's question may blow up your knowledge, perhaps due to false or missing assumptions.

For these reasons, I like to have a "training" on any major new functionality, either as a group, or one-to-one. To verify that the trainee (which could be me) is truly walking away with knowledge, that person will later have to explain it to the next person. And take questions.

To do today

If you're a developer, you're asked to do a lot: deliver creative solutions on extremely tight deadlines that are robust enough to withstand unforeseeable and, frankly, unbelievable misuse and abuse from users. Meanwhile, you have to stay on top of technology, deal with the personalities around you, navigate all the infrastructure, and have a life.

I know all this. I once compiled a list of over a hundred attributes a coder could be evaluated on, and each of those could be decomposed into multiple sub-attributes, so believe me, I do know all this. I lived it for many years.

Still, I'm going to add something to your pile, near the top of the list.

Communicate with your user.

This means getting access as often as possible to product owners. Ask lots of questions right to the experts. Hopefully you do your own demos to them as well.

On a daily basis, you should see someone on the business. "Any reactions to the new order entry screen?" "How are the requirements looking for New Customer?" If it's 3 pm and you haven't talked to anyone on the business side, take a 5 minute break, walk to the trading floor or the sales cubes, or whatever business it is that you support, and ask "How's the market?" "You see what Competitor A released last week?"

If you don't have someone with whom you can do this without feeling awkward, that's a clear indication that you aren't doing this enough. Over time, you'll find some people who are easy to approach and open to talking to you.

Daily conversation keeps you in the loop. More importantly, it establishes a collegial basis on which to have difficult discussions that could come up later. It's going to be a lot easier to ask your sales expert questions about customer demand while setting requirements if it's not the first time in 3 months that you're talking to her.