Friday, April 1, 2011

Escalate With Purpose

One of the best parts of what I do is that I get to talk to a lot of different people with a lot of different styles. I talk with engineers, implementation analysts, support reps, sales people, project managers, and software consumers. Some of these people are incredibly thoughtful about technology and others really just want to accomplish some other task and would like the software to get out of their way.

There are different communication styles as well. Some people tend to downplay things. Others are the chicken littles of the world and everything is a huge problem. Still others simply enjoy the attention they get from being dogmatic; you'll hear "always", "never", "criminal", "unethical" a lot.

When we work with issues in a released software product, they generally start in support. If they're bad they escalate into QA and/or development. The same thing goes with interactions between people.

Discussing an approach, or a problem, or a dilemma can be a great thing. Sometimes, the people in the discussion can't agree or don't agree. At that point it will either be dropped or the discussion will escalate. Someone in that conversation is the first to actually perform an escalation. Conversation escalation can take several forms:
  • bringing in an authority figure,
  • expanding the scope of disagreement (think personal attacks)
  • introduction of defensive behavior and terminology ("always", "never", "only an idiot would", "it's criminal to"), usually with a goal of goading the other party into agreement
For example, an engineer and a project manager I work with were having a discussion about when they needed some content from the client. The content would be bundled into the software, munged a bit for display purposes, and then shipped. They disagreed. The engineer said that he needed two days to do the munging and integration, so two days before shipping was fine. The project manager wanted to pad that and tell the client eight days before shipping. This is a simple disagreement, and one that shouldn't be a big deal. However, the engineer chose to escalate the conversation. He said it would be unethical to ask the client to rush unnecessarily and probably create bad content, and he wasn't going to be part of that no matter what the project plan said or what the client thought.

That kind of overreacting, defensive behavior shut the conversation down immediately. All of a sudden a small difference of opinion was a big problem. The project manager was in a corner licking his wounds, and the engineer was no longer listening to any reality-based opinion and would brook no dissent. Oh, and the underlying disagreement - which should have taken 10 minute - wasn't solved for days.

The moral of this story is to beware of escalation in a conversation. Making dogmatic statements or running to the boss is often not the right way to approach a problem.

If you're going to escalate a conversation, make sure you understand why you are doing so and what you are seeking to accomplish.

There are real and legitimate times to escalate. If the client is asking that we do something illegal, for example, that's something that has to go to a higher-level authority figure; it needs to be escalated. If a coworker is implementing an empirically bad design (and "I don't like it" is not a good reason), then that should be escalated to the engineering team or the architect.

Escalate with purpose, or don't escalate at all.

No comments:

Post a Comment