TITLE: Preventing Employee Issues
AUTHOR: Eugene Wallingford
DATE: February 27, 2007 5:05 PM
Today, I've been sitting all day (except for class) in a seminar
put on by my university's Office of Compliance and Equity Management,
called "Preventing Employee Issues". The presenter is a lawyer who
defends organizations against lawsuits from employees on grounds
of discrimination, harassment, unlawful termination, medical
difficulties, and so on. The idea is that we in attendance might
learn how to do our jobs more effectively, both from the perspective
of our employer and from the perspective of our employees. The
thought of faculty in my department as my "employees" makes me
chuckle almost as much as it would make them, but the legal
effect is the same.
This is the sort of event that I would never have been asked to
attend as a faculty member. And so this is the sort of post I
would never written before, and the sort that
my friend Joe
could probably do without! While I'd rather have been writing
code, I have found the seminar quite interesting. I've always
enjoyed listening to lawyers talk about the law, and this would
have been a bit of fun even if it didn't apply more directly to my
current work duties.
I'm surprised at just how much of the advice we've received is
simply good practice for how any person should live and treat
others. It's almost a re-telling of
These seem like good behaviors for most any part of one's life. They
remain important when you are a manager, whether at a university or
in a software house. The lawyer's essential point is that they
become even more important for supervisors and organizations, because
they create environments in which employees can work reasonably and
thus in which employers have met their legal obligations to employees.
One stream of advice running throughout the presentation is: Document.
Document everything. Document, document, document. Documentation
creates the historical record that supports the actions a manager has
taken, should those actions ever be called into question. Indeed,
even if you prefer not to follow the "good behavior" guidelines above
for moral or ethical reasons, you might decide to do so cynically
because they create a living documentation that you try to create a
reasonable working environment. This is one situation where the
law, both statute and case law, create a "market" in which good
behavior has value beyond a person's own belief system.
The biggest thing I learned is this regard is the importance of
documentation even when you don't think you need it. For example,
when I became a department head, I became supervisor to the department
secretary, whom I consider to be meeting the expectations of her
position. My university recommends but does not require that I do
an annual performance evaluation. The secretary and I discussed
it, and we figured that there wasn't much of a need to go through
all of the paperwork that an annual performance evaluation. But
now I realize that I do need to do the evaluation
annually -- in case I ever need to in the future. Suppose that our
current secretary leaves and we hire a new one. The new person
exhibits a pattern of performance problems, so I decide to do the
annual performance evaluation to help the secretary improve and to
begin to document the problems. The very fact that I did not
evaluate the previous secretary could come back to haunt me,
because the new employee could allege that I was treating him or
unfairly just by evaluating them! This could be spun as a form
of harassment. This may seem like a stretch, but we know how
the law can work sometimes, especially when a jury comes into
play. The safest thing for me to do is "do the right thing" and
evaluate my current secretary, to set the right example and to
create a track record of doing so.
I'm trying to think of a way in which I can relate this to a
principle of software design or programming; it seems like the
sort of idea that bridges many kinds of activity. Maybe this
is similar writing tests for code that you "know can't break",
because one of these days it might, or following the practices
of a methodology such as XP even when they seem like overkill.
These have the sense of "do it anyway" but perhaps not the same
sense of "historical record". Oh, well.
Another stream is that there are a lot of laws that
matter. FERPA, OSHA, and ERISA are just the beginning. I'm glad
that my university should and does provide support to us front-line
managers. One benefit of this sort of seminar is learning what
kinds of situations trigger issues that need to be addressed.
Perhaps the most immediate result of attending the seminar is to
have a small sense of unease about my recent roles on a
couple of search committees.
Have we done our due diligence? Has the university done what the
committee didn't? Yikes. I'd better be sure that we know what we
need to know about our candidates.
- Communicate clearly. Tell people what you expect. Give
specific, concrete feedback.
- Be consistent. Treat everyone the same way. Apply rules
the same way across similar situations.
- Don't make promises you can't keep.
- Do your homework. Do due diligence when you hire, evaluate,
and terminate employees.
- Treat people with respect.
- Be accountable. Take responsibility for your actions. Admit
mistakes and correct them.
- Don't retaliate.
- Follow the rules. Set a good example. Model expected behavior.