On Technical Leadership

::: nBlog :::

Back in 1993 I was working for Ahlstrom, a global pulp and paper company with some unusual strides into early information technology. Not only had Ahlstrom email already in 1981 (naturally called Amail), but I also had the luxury to build a global data network called AGNET (Ahlstrom Group Network) which connected 250 offices into a seamless IP network, running on international half-circuits, X.25 or whatever could be obtained from local providers.

Before the end of 1994, AGNET was one the largest global private networks of its time, and we provided connectivity services to many partner companies and affiliates too, including several universities. This was not exactly pulp & paper or heavy machinery industry, but, hey, it was doable.

Within the AGNET, I had the luxury to experiment with the early Cisco and Wellfleet routers, many times deploying their beta versions and trialing their implementations of new routing protocols like OSPF. Even with only 250 sites, it quickly became clear that link-state protocols were mandatory in order to keep convergence times and internal bandwidth low. Some Eastern European sites were, anyway, still connected with 9.6kbit/s baseband modems over ex-KGB copper wiring.

Now we had our fledgling intranet with early browsers like Mosaic, but users were mostly interested in file sharing and printing services. So within the corporate IT team, we evaluated vendors such as Microsoft and Novell; some acquired units were even using Banyan Vines. This was also the time when there was an arsenal of local area network (LAN) technologies – we were running StarLan 10, Token Ring 4 and 16, 100BaseAnyLAN, 10BaseT all the way to FDDI and CDDI.

During the pre-Internet time, Novell was clearly dominating the marketplace with a server operating system that was technically superior and utilized the most from the concurrent hardware of Intel 286 and 386 processors. Furthermore, they developed routing and service location protocols like NLSP, which had an intrinsic mechanism to ensure that users were always provided the nearest and fastest services what comes to the overall infrastructure.

Now Microsoft, already gaining foothold with their Windows OS and office applications like Excel and Word, were strongly pushing their LAN Manager (and later Windows NT) networking environments. Our then CIO fully bought into their story, with the help of analysts like Forrester and Gartner.

Now being 23, together with my networking team and a perfectly operating global Novell network, I produced an overwhelming amount of evidence that my users were better off with Novell, and, that technically we’d go backwards by switching to Microsoft. At the time my network was running both IPv4 and globally routed IPX (Novell’s protocol) concurrently.

Now history shows that my CIO was right – Microsoft eventually won the battle and Novell shrank into oblivion with their Linux endeavors. This was mostly due to the emergence of web technologies, but in this game only the endgame matters.

I am still grateful to my then CIO for the ‘conflict’, however, since I learned some key things on how to (and not to) manage technical people. For months, he tried to change my technical assessment, while I was trying to change his political stance. All this drained a lot of energy, which could have been directed to more useful efforts.

Now as a CEO, although I still love technology, I’m mostly on that dreadful political seat. Whenever there are critical choices to be made, unlike my then CIO back then, I go to lengths to explain my people the background and bigger (political) picture of any decision at hand. Realpolitik is not that complex, and most engineers can actually understand it very well.

//Pasi