Call me by my name

I don’t understand why people won’t just call others by the names they want to be called. When I was seven years old I decided that I would be Jim rather than James, and everybody supported me. I’m pretty sure my family already called me Jim, but I know that to my kindergarten and first grade teachers I was James. After that, teachers would call me James on the first day of school, but I told them I preferred Jim and that was the end of it. I had one teacher who called me Jimmy, but … well, he was kind of a jerk. He was the gym teacher and I was maybe eight years old. Not much I could do about it.

I encountered someone just like my old gym teacher about 15 years later. He was a higher-up at a bank where I worked. He had the annoying habit of calling people by their given names, regardless of stated preference. He wasn’t directly in my chain of command although he was higher up enough that he could easily have had me fired if he wanted to. Fortunately, I didn’t interact with him often.

When I first met William, he greeted me as James. I smiled and shook his hand and said, “Nice to meet you, William. I prefer Jim.” We had a short conversation. The next time we met he again addressed me as James. I said to him, “William, I prefer Jim. Only my mom calls me James, and then only when I’m in trouble.” That didn’t work, either.

I found out over time that William’s annoying habit of mis-naming people was something of a joke among his subordinates at the bank. I honestly don’t recall if he had that same annoying habit with his bosses. Being young and a little unsure of my position, I let it slide. For the money I was being paid, I could put up with that jerk a few times a month.

As one of two programmer-slash-admins at the bank, I had to support anything computer-related. I guess I’d been there a year when I was to come up to the office to look at a screen one of the secretaries was having trouble with. The problem screen just happened to contain William’s personnel file. The name at the top of the screen was Alfred William <lastname>.

Yeah.

The next time I saw William was a few days later at a monthly meeting with about 50 employees. Part of that meeting involved the head of each department getting up and saying a few words, and taking a few questions. So when William was done with his talk I raised my hand and he called on me:

William: Yes. James?
Me: Alfred … pause … I was wondering about . . .

I didn’t get to finish because he turned red, pointed at me and then the door, and said in a very soft, threatening voice: “Get. Out. Of. Here. … Now.”

Understand, I fully expected to be fired. But by then I knew that my programming skills were in demand and I could find another job easily enough if I had to. I decided that if they fired me, I wouldn’t fight it. Why would I want to work for a company that thinks it’s okay for a senior manager to openly disrespect people? I was laughing as I drove home that night.

I didn’t get fired, and William never called me James again. And I never called him Alfred again, although I did wonder why he had such a reaction to me using his correct first name. Did he have some serious hatred of his given name? Or perhaps he got angry because I showed him obvious disrespect in public. Whatever the case, he started calling people by their preferred names.

I don’t know for sure that the following is true, but I have some evidence to support it.

William went to my manager’s manager and told him to fire me. My chain of command refused, and William escalated the issue to his manager. William’s manager talked to one of his peers, who happened to observe the incident and after some checking around discovered William’s bad habit. William’s manager told William that it was his own darned fault that he was embarrassed in public, and that there wasn’t going to be any retaliation.


Point is, calling somebody by a name other than the one that they prefer to be called by is a sign of disrespect. Actually, of contempt. What you’re saying, when you call somebody by a name other than the one they want to be called by, is that their preferences do not matter to you. I don’t care if that person is a casual acquaintance, or your 50-year-old daughter. If you continually mis-name somebody, you are intentionally being disrespectful, and you can expect nothing but disrespect, or contempt, in return.

Oh, and if I mis-name you–call you by a name other than the one you prefer–please correct me. Be nice the first time. And maybe the second time? I do make a sincere effort to address people as they prefer, but I make mistakes all too often. And, truthfully, I’m more likely to forget your name altogether than I am to call you by the wrong name.

Pondering ultimatums

I had cause recently to think seriously about the nature and use of ultimatums in leadership situations. I’ve come to the conclusion that the ultimatum is a tool that costs the leader much more than he gains, if he gains anything at all. It’s no surprise that I’ve never seen an effective leader use an ultimatum to resolve a conflict.

Before I go on, let me make sure we’re all on the same page. In leadership situations the ultimatum takes the form, “If you don’t do what I say, I will institute this [usually very unpleasant] punishment.”

It’s a tool from the carrot and stick school of leadership. When it works, that is, when delivering the ultimatum elicits the desired behavior, it does so because the subordinate desires the carrot, which the leader has control of, or fears the stick, which the leader also has control of. The leader can threaten to take away the carrot or threaten to apply the stick.

The leader delivering an ultimatum absolutely depends on the subordinate desiring the carrot and fearing the stick. The leader has, in his mind, a “can’t lose” situation: he’ll either get obedience, or the subordinate will suffer dire consequences. He knows that the subordinate won’t choose “or else,” because that’s unthinkable. This can elicit the desired behavior in formal hierarchies like the military, because the ramifications of the subordinate’s other choice are indeed dire: court martial or, in a combat situation, execution. It becomes much less effective as the superior/subordinate relationship weakens. For example, in a volunteer organization the leader’s “stick” is almost non-existent. He’s left with the carrot: the subordinate’s permission to participate.

Things go sideways for the leader when the subordinate no longer desires the carrot nor fears the stick. At that point the leader is powerless, but he doesn’t know it. He thinks he’s delivering the knockout blow, “You better do this, or else,” and is not at all prepared for the subordinate to select “or else.” At that point it’s the leader, not the subordinate, who has no choice. He has committed to a course of action and then surrendered control of the situation to the subordinate. The subordinate, who has already determined that the leader has nothing he wants and has no power to harm him, can then tell the leader, with impunity, to go stuff himself. The leader, even if he’s aware enough to realize that he has lost the battle, has no choice but to bring out the stick and attempt to flog the subordinate, despite the fact that his attempt at flogging makes him look like a fool.

If the leader is foolish enough to allow a subordinate to goad him into a public confrontation, then everybody gets to witness just how weak and ineffective the leader is. Not only does everybody see him fail to control the situation, they see him deploy his ultimate weapon and have it blow up in his face. The subordinate disobeyed, dared the leader to do something about it, and then laughed at the result when the leader took the bait. The leader exercised his authority, but lost the subordinate and the respect of anybody watching the conflict.

The ultimatum is a tool employed by weak and insecure leaders when leadership has failed. Even if it elicits the desired behavior, it does so only out of fear. It forever damages the relationship between the leader and the subordinate, and it will cause anybody who witnesses the confrontation to look at the leader in a new and much less positive light.

An effective leader, on the other hand, establishes control of a developing conflict and works to resolve the situation peacefully and privately. If he determines that there is no hope for an amicable resolution, he removes the carrot or applies the stick without preamble. The leader can do this because the subordinate already knows that he’s crossed the line. There’s no need for the leader to say, in effect, “You have one last chance.” Sure, the subordinate might not care and the leader’s assertion of authority might be meaningless. But he did it privately, on his own terms rather than in response to a final gesture of defiance by the subordinate: a defiance that the leader foolishly made possible and all too often encouraged by his behavior.

The ultimate result is the same, but the difference in perception is tremendous. In the case of the ultimatum, the leader is in effect saying “I will beat you into submission.” And when the confrontation ends with the subordinate still defiant, the leader is shown to be weak and ineffective. But the effective leader calmly saying, “You’ve left me no choice. I must institute the punishment,” the leader is seen as having done everything possible to resolve the situation, but regretfully had to drop the hammer. Even if the confrontation is public, if the leader remains calm and controls the situation he is seen as effective and the subordinate is seen as out of line. And the subordinate’s unconcern never comes into play because he’s never given the opportunity to make that last gesture of defiance.

Responding to errors at Amazon

Saying that Amazon’s servers handle a lot of traffic is an understatement. Publicly available information estimates something like 180 million unique visitors per month in the US. Amazon reported over seven million orders on Black Friday 2017. The amount of traffic we process is just staggering, and the complexity of the underlying infrastructure is mind boggling.

When errors occur, and they do, distressingly often, we follow a four-step process:

  1. Identification. Figure out what the heck is going on. Understand it well enough so that you can move on to:
  2. Mitigation. Stabilize the service so that the error no longer occurs. This might take the form of increasing capacity, rolling back a recent change, making an emergency patch, throttling a noisy client service, etc.
  3. Correction. Modify code or processes to prevent that specific error from occurring again.
  4. Understanding. Study the event more deeply to understand how our processes allowed that error to occur, and how we can improve our processes to prevent similar errors in the future. The output from this step is a Correction of Errors document, or COE.

The first three steps are pretty standard fare: things you would expect any team that is running mission-critical services to do. The last, though, is surprisingly rare in the industry. Some companies say that they do postmortem investigations and such, but often it’s just lip service. More ominously, many times that investigation is an exercise in assigning blame for the error as a prerequisite to disciplinary action. Nobody wants to make a mistake because somebody will end up being blamed, and possibly fired. Error investigation becomes an exercise in CYA.

The COE process at Amazon is different. The purpose really is to dive deep so that we fully understand how we made the error, and how we can prevent making the same type of error in the future. The guidelines for writing a COE specifically discourage identifying individuals by name. The format is well specified. It seeks to answer the following questions:

  1. What happened?
  2. How did it affect customers?
  3. How did you identify the error?
  4. How did you fix the error, once identified.
  5. Why did the error occur?
  6. What did you learn from this incident?
  7. What will you do to prevent this from happening again?

These are hard questions to answer. The “why” section is especially difficult because you have to keep asking “why” until you get to the root cause of the problem. It’s much harder than it seems at first look.

This process of investigation to find the root cause has spawned a new verb phrase: “to root cause.” As in “I need to root cause that problem.” That drives me bonkers. I refuse to use that particular jargon, and I’ve been known to express my displeasure at its use. I fear, though, that I’m fighting a battle that’s already been lost.

COE reviews can be uncomfortable because the reviewers are very sharp and adept at asking probing questions. A review can be especially uncomfortable if the reviewers detect that the investigation wasn’t thorough, or that essential information was omitted. Trying to hide mistakes or deflect responsibility can get one in trouble. On the other hand, a thorough investigation followed by a COE that shows a deep understanding of the error and meaningful action items to prevent similar occurrences can reflect very positively on the person or people involved.

Writing a COE is, fundamentally, an exercise in taking ownership of one’s mistakes, learning from them, and passing that knowledge on to others.

Amazon understands that errors happen. One of our Leadership Principles is “Bias for Action,” which advocates calculated risk taking. Nevertheless, errors can be costly. The COE process is an attempt to gain something positive from those occurrences so that we can avoid having to pay for them again. The COE document is an opportunity for the people involved to demonstrate other Leadership Principles: ownership, their ability to dive deep and understand things at a fundamental level, and their insistence on the highest standards.

In a very real sense, making a mistake can be a positive thing for the company and for your career. I’m not saying that you should strive to make mistakes (after all, another Leadership Principle is that leaders “Are right, a lot”), but responding positively to the occasional mistake can be a Good Thing.

Leadership and development teams

When he can, a leader will explain to his subordinates the reasons for his orders. Not because he has to, but because he knows that people usually do a better job when they know why they’re doing it. In addition, the leader’s subordinates are then willing to follow orders that the leader can’t explain (usually due to time pressure or enforced secrecy) because they trust that he has good reasons.

The leader earns obedience through mutual trust and respect.

Leadership is about building and directing a team: a group of people who trust and respect each other, and work together towards a common goal. It’s also about giving team members the information and authority they need to get the job done, and then letting them do it. The person who insists on being involved in the minutiae of every team members’ job is no leader at all, but rather a meddler who kills morale and destroys the team’s performance.

The best leaders are those who appear to do nothing at all, but behind the scenes they’re getting the team members the information and access they need, and are clearing obstacles from the team’s path before the rest of the team members even know those obstacles exist.

A well-lead team can function without the leader for a surprisingly long time. If the leader has done his job, then his team’s way has been cleared of any looming obstacles, they have everything they need to complete their current tasks, and a good idea of what they’ll be doing next.

In short: the leader doesn’t do the work; he makes it possible for his team to do the work.

The above is as true for a programming team lead as it is for the leader of a military unit or a senior manager of a Fortune 500 company. The team’s jobs might be completely different, but the team leader’s job is essentially the same: create an environment that makes it possible for the team to get the job done, and then step back. Observe. Give encouragement and direction when necessary. But let the team members do the things they’ve been hired to do.

It’s been my experience that most software development teams do not have good leaders. It shows in missed release dates, high bug counts, frequent “hotfix” releases, team member dissatisfaction and flouting of imposed standards, and high levels of past-due technical debt. The result is bloated, crufty, unstable code characterized by tight coupling, low cohesion, quick fixes, special cases, and convoluted dependencies. All to the detriment of the product.

All too often, the “leader” of the team has upper management convinced that the type of software his team is building is somehow different, and those problems are unavoidable in the company’s particular case. He probably believes it himself. As long as management accepts that, they will continue to experience missed delivery dates and their users will continue to be unhappy.

Enterprise

I kind of like the new Enterprise series.  We’ll see how it progresses.  Oddly enough, I’m wondering how big the Captain’s dog is going to get.  That Vulcan babe sure is improbably constructed, isn’t she?

I’m kind of disappointed, though, at how often the Captain or somebody else has to say “…and that’s an order.”  You would think that the “cream of the crop” crew assigned to Earth’s flashiest new spaceship would understand that everything the Captain says is an order.  But then, that’s always bothered me, even when I was in the military.  Whenever a superior said “…and that’s an order,” I knew that he was somehow insecure in his ability to command.