Friday, March 23, 2007

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.


Anonymous said...

This unfortunately is a fact of life and maybe even an American trait. I always think it's interesting that in all leadership type training, examples of great leaders are those who achieved some measure of amazing success. Are great leaders only those people who are successful at completing their goals? Maybe it takes a greater leader to call out that the goal itself is pointless and shouldn't even be pursued. "Quitter" is a dirty word in American culture, but I think it can often lead to dogmatic pursuit of pointless goals that really miss the mark. Maybe we need more quitters.

Anonymous said...

We must also note the dichotomy of "admitting failure" and "accountability". In so many blogs during the SET process, I read about "accountability" for Intel leaders but saw very few comments about rewarding the admission of failures or bad ideas and moving forward.