Can you catch Alzheimer's from someone else?

Your spouse having dementia increases the likelihood you'll develop it, according to a new study:

seniors had six times the risk of developing dementia if they lived with a spouse who had been diagnosed with the condition.

The current best theory suggests that the stress of caring for someone with dementia ends up causing dementia.

My theory is that it's another kind of social virus: the same thing that shows you are more likely to smoke if your friend's friend smokes, eat healthier if your friend's spouse starts eating healthier, etc. -- even if you've never met.  Similarly, men experience "sympathy pregnancies", actually undergoing biological changes.

I'll bet if they look at friends of people with spouses who have Alzheimer's, they'll find an increased probability of developing dementia.

*The 7 Habits of Highly Effective People*

This is an old book that everyone knows.  I was drawn to it by the title.  Effectiveness continues to be a top priority.  Habits indicates hard work, no shortcuts; I'm a believer in practice making perfect.  Highly, as opposed to Super or Awesomely, is understated and again indicates realistic goals.

Also, the title is much better than How to Win Friends and Influence People.  Apparently, we've learned to be slightly less obvious in our ambitions.

I particularly liked the section on being more proactive.  I mentioned in an earlier post that he has the best definition of proactive, one that actually means something.  I don't know if he coined "proactive" or "win-win", but he might have been the one to popularize them.  Now, those words have been so overused that they barely resonate.

Covey also has a strong smell of authenticity.  You really get the sense that he lives what he's preaching, that he would be living that way even if he knew he couldn't package it up and sell it, and gives the whole thing credence.

This book is particularly good for someone who is in a funk, or maybe between jobs, and needs some direction.  He offers practical ways to implement what he's saying, though I found the "private" / personal changes to be more interesting than the "public" / interpersonal one, perhaps because the interpersonal ones have been re-done and re-stated so many times since then.

Proactive people care

"Proactive" is one of those over-used words that you come to hate, even at the same time feeling that it has a rightful spot in the language.  The 7 Habits of Highly Effective People provides a nice definition for "proactive", one that I felt captured what it should mean, elegantly and directly.  (For all I know, maybe the author coined the word himself.) 

In the world of things that you care about, you can only affect some percent of that.  Having a proactive mindset means working to expand your influence over as many areas of concern as possible.

A side aspect of this definition: if someone you work with isn't proactive enough, maybe they haven't figured out why they should care?  (And if that's something that concerns you, maybe you need to try to influence them.)

A different kind of software virus

Turns out if your friend's wife starts putting on more pounds, chances increase that you will too, even if you never met her:

A Framingham resident was roughly 20 percent more likely to become obese if the friend of a friend became obese — even if the connecting friend didn’t put on a single pound. Indeed, a person’s risk of obesity went up about 10 percent even if a friend of a friend of a friend gained weight.

Same pattern occurs for other behaviors like smoking, eating healthy, feeling happiness, etc. Behavior spreads like a virus, like a germ.

The conclusion remains controversial, but it makes sense intuitively, which explains why most of the scientists in the article say things like, "It's still being researched, but I believe it."

It's the same reason why we believe:
* senior managers should effuse optimism at all times.
* a good worker put in a dead-beat group will soon become a dead-beat.
* a co-worker's problems at home will affect the workplace; as a result, people are very hesitant to hire someone having personal problems.
* one bad apple can spoil the barrel.

It also means that if you are following good coding practices and doing great work, but find yourself surrounded by sub-par quality, your efforts will raise everyone else's game. Of course, odds are that you will be affected negatively -- infected, as it were -- but now that you know that, you can focus on preventing that. A little like washing your hands frequently.

Nemesis

"Good team player."

Everyone writes that on their resume, and pretty much everyone believes it about themselves. But what does it mean?

Does it mean you get along with most people, aren't some kind of recluse without any social skills, or a backstabbing, Machiavellian career climber? That puts you in the same group with about 80% or so of the population. Is it therefore some kind of minimal social requirement, just to filter out the extremists and the recalcitrant?

I think it's supposed to mean more than that, or else we wouldn't put it on our resume. I think we mean we're better than most people at getting along, not being selfish. Yet, examining our criteria doesn't yield much evidence.

Enter the nemesis. We all have one. This is the one person we can't get along with at work. Something we do sets them off, or the words they use grate us entirely the wrong way. We can't stand their commando style. They hate our jokes.

I have seen this many times. One example: I knew a tech lead who was competent, but a little soft. The business analyst that was his customer was pretty tough, and would poke holes in everything he did. He shrank slowly over time. They replaced him with someone more confident and a little bolder, and everyone got along fine. Then, ironically, when that business analyst left, her replacement was even tougher. She and the second tech lead battled too much, and couldn't work together. I had a feeling the first tech lead would have gotten along with her just fine. All of these people were able to work with others, but as pairs, they couldn't.

How you deal with your nemesis is the true test of whether you are a good team player. You will have to spend a lot of time listening, really listening to see what it is that causes the friction. This doesn't mean rolling over and being a push-over. Sometimes it means the opposite of that.

But it does mean investing extraordinary effort into adapting yourself so that your interactions are productive.

Because ultimately that's what it means to be a good team player: listening to the needs of your teammates and then adapting your own efforts. It requires tremendous observations skills and sensitivity to words, body language, intonation, work habits, motivations, among other things. Few of us are very good at it.

Think about that the next time you see "Good team player" on a resume, especially if it's your own.

Dead zones

Dead zones occur when the app you work on or the business you support stops growing and starts shrinking.

At first, it's not too bad: there's too many people, and so plenty of hands can help with any problem. Occasionally turf wars break out if people find others encroaching on their traditional area.

Then, inevitably, layoffs reduce the numbers, and the survivors take on larger work loads, usually involving mundane tasks far below their pay grade. Prospects for promotion or developing on new technologies plummet. Morale suffers. Welcome to the dead zone.

The first instinct is to run to your headhunter. I recommend regularly evaluating one's position for learning opportunities and career growth, so this obviously is as good a time as any.

But I also maintain that a dead zone offers some interesting aspects that can be learned from. Here's a brief list:

1. refactoring. During growth times, everyone pumps out code quickly. Slow times can be useful for revisiting things and doing it right.
2. good coding methods. While refactoring, basically you're learning how you should have done it. Next time you build something, you can now do it correctly from the start.
3. processes. What could have been changed in the org so that the "right way" could have happened the first time? Code reviews? Automated unit tests?
4. innovation. During growth, the solution to almost every problem is more people and more code. With strictly limited money and people, think of elegant and creative solutions.
5. expectations management. "No, can't do it" may become the answer to an increasing number of work requests. Learn how to say it while maintaining good ties with users and your boss, and without becoming Mr. or Ms. Negative.
6. team motivation. A stock-picker finds out how good they are in a down market, not by making 30% when everything's up. Same if you're a leader: are you really a good leader or just been getting by because things have been going well? Time to find out.
7. org experiments. Often, org resistance is down because people are trying to figure out what's going on. This is a good time to suggest things you haven't tried before, for example, iterations or daily scrums. Or, more radical things like combining the QA and analyst roles. You can sell almost anything as long as you can make a plausible argument around "efficiency" or "new skills".
8. new responsibilities. People will leave, responsibilities will open up. While some might not be that desirable, and some are, and can be claimed just by doing the work. Should things turn around in the group, you'll emerge as one of the veterans.
9. recharge. The overall pace may slow a bit. Invest in yourself: sleep more, read books, learn new technologies or skills.

The financial world, in the absence of being able to create new financial products, is creating lots of dead zones. They go by the name of wind-down groups and "bad banks". Other industries face similar situations.

Do not stay in this situation out of laziness! If that's in your nature, then force yourself to leave. But if you're a naturally ambitious person, this can still be an interesting, educational time.

Better software through connecting

This past weekend, I went to the dreaded DMV -- Dept of Motor Vehicles. If any government agency brings forth horrifying images of incompetence, bureaucracy, and disaffected employees, it's the DMV. Even though I was just renewing my license, I took a huge book, in preparation for long waits and lines.

I never even cracked the book. I was in and out within 15 minutes.

Actually, I can't remember ever having a bad experience at the DMV. Mediocre, maybe, but not bad. Yet, the imagery persists in my mind, and I would guess most people's.

I was thinking about this because it seems like a large percentage of IT shops have similar reputations. They do decent work, pump out a good share of deliverables, chip away at the list of problems. Yet, they are perceived as slow, lazy, and second-rate.

Some problems are about basic management, all of which practices like Agile addresses: expectation setting, progress tracking, frequent user feedback, quick error identification.

But, it's often not a competence issue. At the DMV, where things were effective enough, what I noticed is that none of the employees seemed happy. Occasionally, you'd see them joke with each other, but the customers were like fish they had to process. All interactions were perfunctory, not personal.

Government agencies don't have a lot of leeway to show personality, but there's no real excuse for a software dev team.

No matter how good your applications are, a weak relationship with your users will doom you to a negative or, at best, mediocre reputation.

If your users work in the same building or nearby, one of your primary jobs is to get physically in front of them regularly. Daily is about the right frequency, for every person on the dev team from the intern to the manager. Ask how things are going. Get to know them as people. Connect.

As technical people, we often focus on the technical specifics that our users request. We neglect the personal aspect of the job. Yet, the definition of a service is that it's personal. The products get outsourced.

It costs nothing to be friendly and engaged with your users. The payoff is that your apps will be better, even if they're the same.

Motivation and complaints

The other day, I met a woman who was full of complaints. Lots of people didn't submit their data correctly, and that created work for her. The building maintenance crew made some lovely improvements, but far too noisily during work hours, which distracted her. And so on.

All valid complaints actually, but I got worried because we were on the same project team. Was she going to drag her feet the whole time for one reason or another?

I kept my concerns to myself and plunged in. And came away surprised and delighted at how productive and helpful she was.

I came to realize that she just liked to have everything lined up before beginning. Work environment, data, clear sense of objective -- once these were in place, she could move mountains. The main point of her complaining was that it prevented her from getting to it and doing an awesome job. She was totally self-motivated, but in the wrong environment, her review might have contained phrases like "reluctant to jump in" or "a negative distraction".

Far from dragging her feet, she actually wanted to race, and cursed the clutter that blocked the starting line.