Data Protection Pointers

eWeek recently posted a slideshow describing several suggestions for planning a data protection policy in a Hadoop framework. The pointers apply to other data environments as well:

1. Account for data protection in the planning phase of the project. Take compliance and privacy concerns into account in the initial design and architecture.
2. Identify data elements that need special protection. What compliance or liability concerns apply to those elements?
3. Does the application need access to the complete, raw data set? Can the data be masked, obfuscated, or desensitized?
4. What encryption requirements do you have? What encryption solutions are available? Do they interoperate with the authentication methods in the environment?
5. Establish standards. It will be easier to keep all the data safe if it is kept in standard templates.

CIO Magazine estimates the value of a data breach at $184-$330 million. Given the cost to an organization's recommendation, there is a business imperative in placing adequate resources and thought behind protecting the data in our custody.

Are Your Budget Priorities Aligned with Business?

A recent article by Larry Bofante of the US Tennis Association raises some important points about making sure that your budget priorities are aligned with your organization:

• What is the return on investment for each item? Does that match with a priority of the organization's leadership? Does it provide a quantitative or qualitative benefit? If not, it needs closer examination.
• Lower your operational costs in order to be able to fund innovation and improvements rather than seeking additional funding.
• Does each project have a business sponsor? If it is not important enough to the organization to be able to recruit a sponsor, perhaps it is not important enough to be done.
• Can the project be done better or cheaper by an outside vendor? If so, make sure that the vendor will represent your organization right.

Are Your Employees Afraid of You?

Nobody likes to screw up. But your employees should not be afraid to bring problems to you. If they do not feel free to bring problems and discuss them, it will take longer to discover and fix problems, and the problems will fester in the meantime.

The key here is to look at how you react to problems. If your first impulse is to attack and blame, you really need to work on that. Make sure that your reaction to problems is positive and resolution-oriented.

Ask questions and make sure you get the information. Your first response to needs to be to contain the damage, and that is not going to happen if you reduce your employee to a quivering puddle of fear. Find out how bad it is, and what your employee thinks happened.

From there, communicate out to affected people. I usually ask someone who is on the team but who is not an expert in the technology in question to take the lead on communications and notifications. You should notify your own boss. That leaves the technical experts free to concentrate on identifying and troubleshooting the problem.

Set up a bridge line for communications. Don't let it be captured by people who are asking unanswerable questions. When that starts to happen, break in with a situation update and the current state of the resolution plan. (Sometimes, that may just be a list of the possible causes that you have ruled out.) Make sure that there is a sense of forward motion and progress. If people insist on asking unanswerable questions, tell them that there will be a postmortem to discuss the causes of the problem and the long-term resolution plan.

Part of a manager's job is to make sure to fly air cover for your technical staff when they are working a problem. They can't concentrate on a resolution if they are constantly being asked "are we there yet?" Ask them for regular updates, but all other communication and updates should flow through you. If necessary, set up a separate bridge line for technical experts and keep the non-technical people off of it.

After the immediate crisis is over, hold a postmortem session to dissect the problem, the team's reaction to it, and how to avoid the problem in the future.

Then, if it is necessary to reprimand your employee, do it humanely and professionally. Reprimands should be direct, clear, private, and over. Don't let the problem drag on, and don't let it fester.

Conducting Effective Reviews

CIO Insight recently had a slideshow article describing several suggestions for conducting performance reviews. Here are several of the key suggestions:

1. Collect information throughout the year. As one of your team members completes tasks, file information about those tasks in a folder or other location that will be easy to find at review time. That will allow you to avoid a recency bias problem when looking at a full 12 months of performance.
2. Communicate throughout the year. Make sure to provide feedback throughout the year. Your comments on the performance review should not come as a surprise to the employee; they should all be things that you have discussed previously.
3. Gather feedback from a broad range of project managers, customers and peers of the team member so that you are getting a balanced look at the strengths and weaknesses of a particular person.
4. Allow the employee to have enough time to fill out the self-assessment portion of the review. The employee should have at least a week to provide feedback.
5. Consider the environment for the review. If possible, hold an in-person review in a neutral location, away from email and phone interruptions.
6. Walk into the review ready to listen. Ask open-ended questions. Show a real interest in the sorts of progress that the team member wants to make.
7. Before the review, make it clear that this will not be a compensation review, just a performance review. Removing money from this discussion will allow a better discussion of employee growth and goals.

Happy Mother's Day!

Selling Yourself in an Interview

I recently gave some advice to an experienced professional who is wondering if her experience might be considered a liability. Age discrimination is a real problem, since there tends to be a bias towards hiring inexperienced people who can demand a lower salary.

This is the advice I gave her; I'd be interested in your feedback:

Explain to the interviewer what you are going to do to improve their organization. Convince them that you would be a bargain at your rate. Do your research ahead of time to find out what the boss and the organization need, and explain why your mix of experience is the best possible fit that they will ever find.

Experienced people can be far more productive than inexperienced people, but they need to demonstrate the attitude and drive to accomplish to their potential.