Knowing when to fold

When I was at Oracle during the 1990's, I got to work on this huge framework called Sedona. After Oracle invested several years and hundreds of people working on it, I joined the project and was building the entire web front end for the tool (the web was brand new back then, remember).  Then,  I read one day in the press that the project I was working on had been canceled.  I left Oracle that day, because I felt like I should have heard that my project was canceled from inside Oracle before I read about it in the press.  I didn't disagree with the decision, but I did feel like the management culture at Oracle was not healthy for me spiritually at the time.

The architect for Sedona was a very bright guy named Chris, who went on to Microsoft to help create the COM+ distributed transaction framework, and then the wildly successful Common Language Runtime that's part of Microsoft's .NET framework.  I had lunch with him a few years ago when I was working there as a Principal Development Manager, and I'm really glad he found an outlet for his professional creativity.

Chris and I have never talked about this so I don't know what he'd say, but I think some of his Microsoft work bares the marks of "doing Sedona right the second time at Microsoft", and I really see his Oracle and Microsoft work as part of a continuum.

Oddly enough, in my current consulting work, I've had an opportunity to learn this enterprise computer system called Pivotal.  It's pretty close to what Oracle was trying to build with Sedona, and I wonder now whether there were any former Sedona people on the Pivotal team.

UPDATE 4/14/10: I talked with Martin Stiby (a really bright and very nice geek) at Pivotal and he told me that the design did not come from Oracle or Sedona, just to set the record straight.

I think one of the hallmarks of a great CEO is that they have a good track record of knowing when to fold and when to double down.  Sailing metaphors were really popular for a while in management consulting.  When is the wind going to shift a certain way?  How does the team on the boat adapt as a group to a constantly changing wind and then win a race?  Maybe they're not always right, but they're right enough to win.  Given Larry's track record, I would give him the benefit of the doubt on this one.  How did he make this decision?

I think knowing when to persevere, and when to call it quits is a key skill that is transferable to many parts of my life.  In software development, I see this in development, debugging, testing, management, user interface design, and more.  Often, such decisions are made by individuals and no one may even know that a decision was made. But also these decisions must be made by groups, and it's here where culture can play a critical role in helping the group make the best decision.  Whether it's the board or the executive team or your daily engineering stand up meeting, culture helps groups pool their collective knowledge and make wise decisions about when to fold.