As I mentioned, I’m visiting the StorageTek facility in Louisville, Colorado this week and next. I find that there are two distinct aspects to what I’m doing here. The obvious bits are the formal meetings – reviewing engineering processes, planning various meetings between Sun and StorageTek engineers* (including a big colloquium next week), and coming up to speed on key programs and technologies. Those are keeping me pretty busy. Less obvious are the ad hoc interactions, on topics ranging from programming tools to document archival, from differences in IT infrastructure to the various techniques used for gathering customer requirements.

If you think about it for a minute, the task of integrating two large companies is truly daunting. There’s a fine balance to be struck. At one extreme would be treating StorageTek as “separate but equal”, operating it as a wholly-owned subsidiary with little or no day-to-day interaction. At the other extreme would be Borg-style “assimilation”, submerging all traces of StorageTek’s culture and practices. Neither is appropriate to this situation. StorageTek is a successful, profitable company, highly regarded by its customers: it’s critical that we preserve that. But both Sun and StorageTek have been limited in what we can do historically: Sun because of an incomplete approach to storage, and StorageTek by a “plug compatible” business model that inhibited innovation at the edge of their systems. The value of the merger is that each company offers new possibilities to the other. Together we have more choices: more ways to address the acquisition, processing, and storage of data from end to end. For me, the way to achieve the right balance is to encourage the business unit managers to conservatively adapt the organization, projects and products to ensure business continuity, while at the same time developing a network of the key innovators – architects, researchers, engineers – to open up the possibilities of radical synergy.

Back to the daunting nature of the task. Like all such endeavours, the elements usually turn out to be simple: meetings of individuals or teams to identify and solve pieces of the jigsaw puzzle. And the ad hoc interactions provide the “jiggling” that allows the pieces to fit together (or sometimes identifies a piece that’s in the wrong place). We never budget for these activities, but without them it’s really hard to finish the picture.

—
* Yes, I know that we’re all Sun now, but I need some language to refer to the two groups. Maybe oSUNW and oSTK, for “originally Sun” and “originally StorageTek”.

I flew out from Boston to Denver this afternoon for a ten-day visit to StorageTek. I have an unusual role in all of this, with one foot in engineering and the other in human resources. My main objective is to facilitate the smooth integration of the Sun and StorageTek engineering communities. Now as you’d expect there are groups busily working on what the merged organization structure should look like, who reports to whom, and what the engineering deliverables are; similarly there are HR teams mapping job grades and benefits and stuff like that. I’m not trying to duplicate their efforts. My focus (colleagues might call it a long-standing obsession) is on connecting the engineering community: bringing together creative engineers who might otherwise be isolated in “stove-pipe” organizations, fostering the kind of conversations that create new opportunities. For me, the person who put it best was Lou Gerstner of IBM. Here’s an excerpt from an interview with BusinessWeek about his book Who Says Elephants Can’t Dance?

Q: In the book, you use the phrase “counter-intuitive corporation.” What do you mean?

A: There is this view that has been prevalent for as long as I’ve been in the business world that large companies are slow, ineffective, and that small companies are faster, better, more entrepreneurial. I don’t buy into that. It’s harder to make large companies faster, entrepreneurial, more responsive. But it doesn’t mean they can’t be that way.

This is probably the subject of another management book, but this is all about creating organizations where knowledge moves in a different way than control. Large companies have to have elaborate systems of control because there’s lots of things to count, oversee, report, and add up. You create this kind of skeleton of an organization, which keeps it upright and moving. But you don’t want knowledge, which is what people really leverage in a large institution, moving along the same pathways as control.

You’ve got to free knowledge so that it moves horizontally in an organization, not hierarchically, and allows organizations to leverage the fact that they have a big presence in various markets so they know things. That knowledge can move across the enterprise. Smaller companies have no way to leverage information.

So that’s what I’m up to, in a variety of ways: fostering the horizontal flow of information. To me, that’s what makes the difference between a bunch of engineering teams and an engineering community. And we’re not just talking about product development: this has to include research, development, manufacturing, pre-sales, consulting, and support. More anon.