Managing Disagreement

Here is an interesting article I read this week, "Getting to the Heart of a Disagreement – and Resolving It," by Roger Schwarz.  I often wonder why good people who want to do the right thing so often disagree and seem unable to resolve the disagreement.  Schwarz argues that we waste time looking for common ground when we should be analyzing our assumptions, interests, and facts to find the heart of the disagreement.  Once we can find a specific aspect of a problem on which we disagree, then we can work to understand the disagreement and try to craft a solution that puts us back on the same path.

It is election time, and observing the rhetoric of the various campaigns, it seems that candidates are put into a position where they must try to diverge from their opponents in order to win the race. Even when elections are over, our elected officials are always living with the specter of the next election.  This competitive approach to governance seems to value winning over collaborating.  How can our government solve the really big problems of society in this competitive environment?

My own approach to disagreement in the workplace is to remind myself that we all want to do good work and to help our university be the best it can be.  Good solutions are what we should seek, not winning in order to build our own importance in the organization.  Of course, position in the organization gives us our platforms from which to influence others, but we should strive to downplay our own positions and importance in favor of the great solutions to problems.  We should all strive to be leaders in problem solving, and that means working to resolve disagreement.

It's Not the Person, It's the Process

I first learned this mantra years ago, when our department was heavily into Total Quality Management.  It is one thing that has really stuck with me.  If there is a problem, addressing the process issues first very often solves the problem. 

When a complaint comes in, it can often be difficult to determine what really happened and who is at fault.  Often, what is at fault is a process issue, but the blame frequently falls on the person or people involved in the process.  For example, suppose a customer asks for assistance and gets the answer, "I don't know how to help you with this."  On the face of it, there is nothing really wrong about this response.  The service provider is telling the truth.  Would we rather have a lie?

The problem is with the process.  If we don't have a good process to tell the service provider what to do next, then the customer goes away unsatisfied, the issue is not resolved, and we get a black eye.  Even worse, the customer spreads the word:  "Don't go for help there.  They don't know any answers."

In this case, what we need is a good escalation process, so that the service provider knows what steps to take next in order to get the customer to someone who can solve the problem.  Solve the process issue, and the problems go away.

Of course, this approach does not solve all problems.  Occasionally someone really is at fault.  Sometimes people don't do the right thing.  But having good processes in place, or adjusting the process when something is going wrong, solves lots of problems.  Let's start with process improvement and see where it gets us.

Remember:  It's Not the Person, It's the Process

Thinking About Customer Service

I had an interesting customer service experience this week.  I have my mother's power of attorney, and I am managing her finances for her.  Since she lives in Michigan and I live in Minnesota, managing her finances occasionally becomes problematic.

Last August I closed her checking account and opened a new one for her, since she had been the victim of identity theft and unauthorized charges were being made to her account.  This required me to change several automatic payment withdrawals from her old account to her new one.  This all seemed to be working well, so I closed the original account.

Then I received a bill from one company, which I took to mean that the automatic payment form had not been accepted.  When I called the company, after some time in voice-mail jail, I finally got to a service representative, who told me I would have to resubmit all of the documentation.  Since this involved getting my mother's signature on several documents, I was feeling mighty frustrated. 

Last night I got a call from the company asking me to take a phone survey about their services.  I was happy to answer the survey, giving responses like "very unhappy" or "completely unsatisfied."  Boy, did that feel good.

Today, I got a voice mail from a customer service representative from the same company, asking me to call her back so she could help me resolve the problem.  Well, I thought, why not?  When I called the number she left, I got back into voice-mail jail, where I hung out for about 20 minutes, and then I gave up.  Grumpy again!  I thought, well, I'll just send in all the documents again.

Then, this afternoon, I got another call from the same customer service representative.  Within five minutes, she found that they did indeed have the correct document on file, that the automatic withdrawals had been working, and that my mom had two month's credit on her account, since I had paid it twice.  This customer service agent, Amy, was diligent in calling me twice, efficient in correcting the problem, and helpful in offering to send me some other information I will need.  All is well.  I told Amy that I would be happy to answer the company survey again, and that this time I would be much more complimentary about their service.  I still don't like their voice-mail jail, though.

I think direct customer service is very hard, and I do try not to take my frustrations out on the person on the phone.  I also have lots of empathy for customers, since sometimes I am one.  I want our ITSS customers at UMD to be happy and get good service, but it is an imperfect process, often because human communication is an imperfect process.

I liked the processes of the company I dealt with this week.  I like that they had a follow-up survey, that they reviewed the results of the survey, that they called me back twice, and that they fixed the problem.  Maybe we in ITSS can take some lessons from them.

Making It Simple

Here is an interesting article, "The Simplicity Thesis," by Aaron Levie, CEO and co-founder of Box.  In this article, the author calls for attacking a complex problem and producing the simplest solution.  He gives many interesting examples of products you may be familiar with that meet his Simplicity Thesis.  You won't have far to go to find equally compelling examples of complicated solutions to complex problems.  Think about how many features you use regularly in your favorite piece of software, and then compare that with the number of features actually available.

At the University of Minnesota, we are having intense discussions about aligning IT.  IT at the University is highly decentralized, with IT units and staff on all campuses, in most colleges, and in many administrative departments.  When any one of us comes up with a solution to a problem, how simple is it?  Often it starts out pretty simple, but then we encounter security regulations, audit requirements, compliance issues, integration with other systems, and user training.  When we all do our own thing, good as those things might be, what does that do to our IT ecosystem?  The complexity of IT solutions as a whole is huge.  Would we benefit by simplifying?

Aligning and simplifying does not always mean centralizing.  We have all seen how a centralized solution, which must meet many needs, can become very complex.  And it can also take a long time to implement.  And in the end, it might not meet the simple need we started with.

Alignment is being defined as we work on this project, and I sure hope we come up with a definition and a set of practices that meet Levie's Simplicity Thesis.