The Impact of Culture on Innovation
Posted by rbpasker on January 18, 2008
Like most people, I suspect, how I feel about what I’m doing has a lot to do with the culture of the place I’m working. When I’m working with great people (or alone!) on an interesting project, I can be amazingly productive.
But in an environment where I feel undermined, or I am competing with other groups in my own company, or the company seems to be driven by raw power and power relationships, then I feel like I have no choice other than to bail.
This has happened a few times.
For example, when I was at Ingres in 1989, I worked in the Ingres/Net group, which was comprised of an eclectic group of 5 or so talented people who couldn’t get any of their ideas implemented because all of the decision-making power in engineering was held by the (also extremely talented) database server group and a few people in the front-end group who had been at Ingres for a long time. Ideas, no matter how good, that did not originate inside the power structure were summarily ignored. I don’t think any of the people in this powerful group thought there was anything wrong with the way things were. They just knew what they wanted to do and how they wanted it done, and everyone had to follow suit. I left after 9 months.
On the other hand, at WebLogic, we had a pretty good free flow of ideas. Over the course of 18 (very long) months, I single-handedly wrote most of GA server code that BEA bought (the database and html code was written by others, and we had a major release in the works at the time of the acquisition which had many contributors). The question I had to deal with as we started to hire people in January of 1997 was, how was I going to give all the new people coming on board a feeling of ownership over the server code.
Well, we had a bunch of things going for us:
- a talented A-Team of new hires, who believed in the company and our mission of “Elevating Java to the Enterprise” , and were itching to get to work
- I couldn’t continue to write code because I needed to hit the road and pitch customers. We were evangelizing a new category, and many of the sales people and Sales Engineers initially struggled with the presentation, although they all eventually became wildly successful at it
- unlike a lot of one-person crash programming projects, the code base was in reasonably good shape
- I had promulgated a hands-off testing framework, which was developed by BobA (who we lost many years ago in a swimming accident). This kind of testing framework is now institutionalized as “Continuous Integration,” and some of the WebLogic engineers later built and sold a company around this concept.
The result was that we had a very independent, yet cooperative, development team all working under one roof. People adopted or were assigned pieces of the system, like RMI, httpd, EJB, JMS, etc., and they worked on them independently. To provide consistency across the product, I instituted a set of “councils” on each subsystem, as well as on broad topics like security, management, and networking, that included me (as the chief architect) and a cross-section of 3 or so other members of the engineering team. Everyone in engineering was on at least one council, the monthly agendas and minutes were published, and anyone could come to any council meeting and contribute. I can’t say that every council functioned successfully, but what the councils did accomplish was to set a tone of of collaboration and the free flow of ideas across the engineering team. I didn’t need to make or approve every decision, and people learned to rely on their peers. That tone, I feel, spurred people on, because (unlike Ingres), people could get their ideas heard and incorporated across the product.
Following the acquisition by BEA, we faced something we had never experienced before: competition from the inside.
A week before the offer was announced, as part of the secret acquisition discussions, I went to a hotel conference room down the street with my laptop, and sat at one end of a long table filled with super-smart BEA technical people who were there to conduct technical due diligence. Eight hours later, I was flabbergasted. Nobody, except maybe one person, really knew what BEA was buying in WebLogic. They thought they were buying some sort of fancy web development system, like Cold Fusion, to act as a front-end to BEA’s leading product Tuxedo. Nothing I said in that room (“we have transactions, we have clustering, we have connection management, we have remote objects, we have message queueing, we have TP monitor underpinnings, etc.”) or showed them (I had my laptop open running Emacs on the source tree), would sway them.
This was quite a personal disappointment, because of all the possible acquirers (Sun, Netscape, Oracle, SAP, IBM, etc.), surely the BEA people would understand that what we had built was a Java-based TP Monitor. In fact, a group of us had gone up to IBM in ’97 to talk about WebLogic with the IBM software group, including Don Ferguson, the father of WebSphere. I have to say, the IBM folks really got it when we talked to them that day. Of course, we were dissapointed that they didn’t license WebLogic. Years later, I heard that IBM eventually spent a billion dollars to catch up with WebLogic.
Up until that point, BEA had been assembling a CORBA-based successor to Tuxedo, called “Iceburg”, first renamed “M3”, then, hilariously, renamed “WebLogic Enterprise.” M3 sold about 8 copies in total (I don’t have anything to back this number up, but I think its close to accurate!). The idea that a puke-y start-up from San Francisco with 20 developers could challenge the supreme legacy of Tuxedo was the rain shadow under which the acquisition took place.
At our first integration meeting, which included about 40 technical people from both companies, the topic for discussion was how were we going to turn WebLogic into a “web front-end” for Tuxedo. BEA’s Jolt Java client product for Tuxedo would be the lynchpin.
As you might imagine, I didn’t take well to this dicusssion. Having been one of the principal developers of a powerful TP monitor for VMS (which, after 20+ years, still powers the Citibank Funds Transfer Network and the Bank of New York’s Government Security Clearance System ), and having read the Tuxedo book, I knew what Tuxedo could do, and WebLogic was well on its way to being the web-based, OO successor to Tuxedo, TopEnd, and Encina. And I was right.
It was not only the technical people at BEA who were predisposed against WebLogic. Six months after the acquisition, I went to a strategy meeting at a Very Large Manufacturing Company, with a large group of BEA sales executives and technologists, and the local former WebLogic sales rep. In the pre-meeting meeting, it was predetermined that we were there to sell them M3 because they were a CORBA shop. Never mind that WebLogic had had many customers using CORBA successfully with our server product; the corporate mandate was sell M3, and no one in the room wanted to hear anything else.
I figured that if I was going to stay at BEA as Chief Architect of WebLogic, I would have to continue to deal with these kinds of issues. But endless political fights with closed-minded people was never my strong point (to say the least). I had to find something else to do.
WebLogic had had very good success selling WebLogic to ISVs as the underpinnings for eCommerce and content management products such as Moai, Vignette, and e.Piphany. But we decided that we were not going to compete in those markets because it would make it more difficult to acquire new ISVs, a major indirect channel for us.
At BEA, however, there was no such compunction. In early 1999, I lobbied to head up a new group that would accelerate the development of “verti-zontal” applications, that is, vertical apps that could be applied across many different industry sectors, such as a portal and eCommerce and content management systems. It took another month of lobbying to get even 2 developers. We all moved into one office. We started whiteboarding.
Then the calls started.
The rumor had gotten around about what the Vertizontal group was trying to do, and I got phone calls and visits from engineers, managers, directors and VPs from San Jose, Texas, and New England, who were tasked with building the exact same thing! Four separate groups, in 4 separate states, from 4 separate acquired entities, all within one mid-cap company, were now in competition. We were all starved for resources, we all had different ideas about what we wanted to do, and we all reported into different parts of the organization.
I attempted, obviously unsuccessfully, to get everyone working together, but the politics took over. Who would be in charge? Who would lose headcount to this group? What would be the underlying platform? What would happen to the managers and directors who were no longer needed by this consolidated group?
In the end, I don’t know what happened to the other 3 groups. I left.