Gimme Some Mooly

I would encourage every employee to read the February edition of the MPG Bulletin written by Mooly Eden. He talks about the difference between efficiency (doing things right) and effectiveness (doing the right things). He also talks about killing off products during engineering or development when it's obvious they aren't going to be successful, and finding the "wow" factor for every product he works on. I consider his newsletter to be the best Sr. Management communication happening at Intel. It's not self promoting. He addresses real problems. The style is upbeat and positive, but not filled with the type of cheer leading that has become typical at Intel. This one short newsletter encapsulates so much of what is great about Intel, and how effective leadership can really make a difference. For any VPs reading, go take a look at Mooly's newsletters. That's how it is done.

He points out that that part of taking risks is knowing that some things are going to fail. He gives an example of killing off a product and then realizing he could have shut down even earlier than he did. He didn't realize that it should have been stopped sooner, but I'll bet someone on his team did. And if so, why did it take another two months of work on an already dead product to get it stopped? This is not an uncommon situation, and Mooly stopped short of addressing why it's hard for teams to kill products, programs, or projects.

The answer is that, with the exception of Mooly and a few others, we all think we have to be right all the time. If you propose a product that fails, you risk being associated with that failure. Most project managers get vested in their projects and want to see them succeed. Nobody wants to see months of years of their work amount to nothing. Most of us resist pulling the plug even when it's obvious that success isn't possible. And in many cases people working on these products know they won't be successful, but they aren't the decision maker.

Employees would be more willing to identify programs and projects to be cut if there was less personal risk. It's hard to kill a product or program. But it's much harder to suggest to your management that a project should be killed. I've worked on large programs where my boss (and their boss) staked their reputation on it being delivered, or being delivered on time. Hearing something like "We're really against the wall on this one, we can't afford another slip" is fairly common. Even harder to deal with is "We've spent a fortune on this thing and we need to make it work." During one particularly bad year I was tasked with implementing an enterprise tool that someone had already spent money on. It was expensive, had not been successfully implemented at any other company, and would require a lot of business process change. Suggesting that we either try to get our money back or wait for the next major version was met with a fairly hostile reaction.

It's one thing to suggest that something won't work because you don't want it to succeed, or because you don't understand it. That's negativity and cynicism for the sake of it. But having some data or information that demonstrates how and why something can't be successful is exactly the kind of information managers should crave. But they don't. We (yes, I'm including myself in this group) think we can find ways to make things successful. "Maybe is just needs more time? I know it's not working now, but we'll get it right in the next version." Or it's the situation I described above where a more senior manager isn't open to hearing that something is going to fail.

People need to have the faith that they'll get rewarded, or at least not published, for speaking the truth about product or program issues. The issue is that we don't measure success on these terms. I can't think of any metric at Intel that tracks how effectively someone saved the company from taking a wrong turn. Some Sr. Managers (perhaps Mooly) may do this. But right now the only measure of success is success itself. We need to figure out how to make it safer for people to speak up and drive the right product changes sooner.

Ch-Ch-Ch-Changes follow-up

I had some good responses to the last post. I recommend reading the comments if you haven't done so. I also got a few emails and wanted to share some of that feedback well. One person noted that most Intel people aren't as generally upbeat as they used to be when replying to a "how's it going?" question. They noted that most people are just "fine" or "hangin' in there" rather than something like "great!" Another emailer mentioned that there appears to be a lack of autonomy and empowerment that we had previously, leading to lower morale. People still have a lot of work to do, but they feel less personal ownership and responsibility, at least in IT. I'll need to think about this one - is it a cause or a symptom? And is it an inevitable result of IT becoming more process focused and moving to standardized tools?

A couple of people asked about the internal blog that I've mentioned a few times. I'm hesitant to post the full URL of the blog because it contains the last name of the blogger. Given that he's already out there with another blog this may not matter, but I'd rather play it safe with someone else's identity. From the Intel network go to blog.intel.com, then click on Employee Blogs, then scroll down to the Ms and look for the only blog with the number of comments over 1000. If these instructions don't get you to the the blog, try this: ask the person sitting in the cube next to you for the URL to Jeff's blog. If that doesn't work, try the person on the other side of you. Good chance that one of them is reading it. There are several other good internal blogs as well, and Jeff has conveniently just mentioned some of them. So going to his blog gets you pointed to a bunch of others as well.

BIG EDIT: I took this post down yesterday when a couple of you emailed to asked what the heck I was talking about. I had a couple of paragraphs in here about earnings that didn't make sense. As I've mentioned, I work on many posts at once and had pasted another post into this one. I couldn't get to it yesterday to fix it so I just took it off line. Sometimes I wish I had an editor.

Ch-Ch-Ch-Changes

Some changes are taking place that I thought were worth mentioning. I've gotten several "I'm leaving..." notes from Intel people over the last week. Perhaps I wasn't paying attention, but it seems like we're either at the beginning or the tail end of another round of layoffs. Assuming people had about 2 months to find another job this would mean that they were given notice in early January. Or they just got laid off. The notes I've gotten are more from professional acquaintances rather than close friends, so I'm not asking about their circumstances. All of them seem to have landed good positions elsewhere, and their messages sound positive. Some genuinely good people are leaving us, which is inevitable with layoffs. What's odd is that I'm not hearing anything about these people leaving beyond their goodbye notes. I wonder if we've all become a little numb or accustomed to people leaving?

Our CIO has reset his expectations for monthly status reports (MSRs). He now wants us to do a short update for each quarterly deliverable we have, and then mention anything else we worked on. We should see more succinct MSRs with less marketing spin. I'm not quite arrogant enough to presume that my post on this topic was the reason for the change. But maybe I was able to influence someone who mentioned to JJ that writing long MSRs was not a good use of our time. (It's my blog, and I'll have delusions of influence if I want to.)

I just recently noticed another, more subtle change that's been taking place over the last 2-3 years: Intel people don't hang out after work the way they used to. I still have my circle of Intel friends, some of whom are in my smaller circle of close friends. We don't socialize outside like we used to. It could be that we're all getting older and other obligations keep us from stopping for a beer after work. But the old stomping grounds aren't full of Intel people they way they used to be. I'm not sure why this is, or what it means.

I also notice that people are generally working less than they used to. Don't get me wrong - I think this is a good thing overall. I used to get emails from many people well into the evening. Now it's rare that I get e-mails very far outside of business hours, except from people in different time zones. People used to work long hours for two reasons: the first was that they had to. This seemed to get increasingly common in IT and eBG as we were trying to roll out bigger, more complex solutions. But before that and until the last few years many people wanted to work long hours to get their jobs done better. Some were workaholics, but many just wanted to get the work done and appreciated an hour or two in the office when it was quiet. I still see people at work early and late, but far fewer than previously.

Part of this may be due to telecommuting, but if that were the case my inbox would still be getting hit with mail in the evenings. I'm guessing this is due to a combination of the depressed and flat stock price, and more recently the environment of layoffs. It could also be that Intel is driving people less hard to feel competitive every hour of every day. Do you see the same thing?

Little Black Book II

My last post didn't go over terribly well. Some people didn't get it, and a couple outright disagreed with me, which is fine. But what they disagreed with indicates to me that I did a poor job of making my point, which was this: you need to have the right solution for the problem being solved. I'm not opposed to CMMi at all, but I haven't seen any data that shows how it addresses some of the problems that IT is trying to fix. It's being held up as the one vehicle that got Flex Services (an IT team) on track. Again, I haven't seen the data. Flex getting better and them using CMMi is a correlation, nothing more. But my point isn't that CMMi is wrong or bad, just that it's not a substitute for knowledge, experience, or education.

And this gets us to the heart of the problem. How many people in IT throw more resources at a project when it gets behind schedule? How many can't see some obvious people bottlenecks in projects or programs well before they hit them? Why do projects continue miss dates for the same reasons they did years ago? Largely because this stuff is hard and unpredictable. We can't predict what a vendor will do. We can't predict that people 1/2 way around the world won't hit their deadlines. We can't predict that integration of two different systems isn't going to work well. Right?

This stuff is hard, but it's always been hard. Why are some people are really good at it, and rarely miss deadlines or resources estimates? What do they know that we don't? I think it's the knowledge that the chaos of IT systems is usually predictable and manageable. Process certainly helps, but it's the understanding of how these things work, regardless of the technology, that makes it more manageable. And more importantly, it's understanding how the people work that makes estimation successful. They work in largely predictable ways, and despite this we are constantly surprised by how teams behave.

So where is this font of knowledge? How can everyone acquire these magical skills? Some of it is experience, but a lot of what's required is knowledge and a different set of skills that have been developed over the past 30+ years. So here are some recommendations: send everyone in IT through a basic project management course. I'm still amazed that some people can't reliably manage tasks to time lines. And yes, send those who need it through CMMi training.

There are also some IT books that should be mandatory reading for all people, program, and project managers. The knowledge in these books would add far more value to IT's productivity and Intel's bottom line than CMMi. The first book that managers need to read is The Mythical Man Month. Also, Death March and Peopleware should also be required reading.

These may be somewhat dated, particularly the Mythical Man Month, and they are not a panacea for all the problems facing IT. And there are tons of other excellent books, perhaps even better books, on how to manage technology and people. But when I see people who don't understand some of the basic concepts outlined in these books making multi-million dollar resourcing decisions it makes me want to strangle them. Having broader knowledge would give us a level playing field for discussing and managing our projects and resources.

So maybe over the next six months or so we'll see some managers walking around with one of these classics that is new to them rather than the latest book off the Harvard Business Review reading list. Any other recommended reading for IT?