On migrating from CCMail to Exchange, the cultural shift nobody predicted, and a boss who taught me that the best business planning happens on a tablecloth.
The Novell migration to Windows NT and Cisco routers implementation had cleared the network. The desktops were running Windows NT Workstation. Applications that had frozen and stuttered for years were suddenly responsive. People who had kept novels beside their keyboards to fill the waiting time were no longer waiting. And yet something was still wrong. Something I had not noticed as I was too busy until this point.
This is what happens when you solve a big infrastructure problem. You start noticing the smaller applications problems that still exist. And now, with the infrastructure noise gone, a different problem came into sharp focus.
Nobody was really using email. Phone calls, faxes and even walking to people's desks and offices in the other building was the preferred route of communication because it was faster and more reliable.
How CCMail Actually Worked in Practice
The company had CCMail, which was a perfectly functional email platform for its era, but it had fallen behind and got overtaken by more and better email solutions. Our cc:mail installation was especially impressively lousy. The post office server was sitting on a simple PC that was at least put in the server room (unlike that server we discovered in the loading bay...). A real server was not deemed necessary and it would have not helped, as the cc:mail was antiquated — to put it mildly.
On slow, unstable machines with unreliable network connections, opening a CCMail client was an act of commitment. Synchronising the inbox could take long enough to justify making a cup of tea. Checking for new messages was something most people did occasionally, when they remembered, on the more powerful machines that had been configured to sync automatically perhaps every thirty minutes, if conditions were favourable. The MD had his machine set up to send out all email on a Friday afternoon after he had left for the weekend.
For many staff, the practical workflow for email communication went like this:
First, send an email. Then, pick up the phone. Tell the recipient you had sent them an email. Wait while they opened their CCMail client. Possibly call them back in ten minutes when the sync had completed.
It was, in effect, email as a telephone attachment. The message was the confirmation that something was coming. The phone call was the actual communication.
This was not laziness or technophobia. It was a completely rational adaptation to a system that had never worked reliably enough to be trusted on its own terms. People had adjusted their behaviour to the constraints of the infrastructure, and those adjustments had hardened over time into habit.
The cc:mail system was a continued embarrassment, especially when compared to how well the major server and router project went.
Planning on a Tablecloth
By this point I had earned a measure of goodwill, enough that when I met with my boss in Munich to discuss the next phase, the conversation had a different quality to it. Less diagnostic, more strategic.
My boss had a specific view about how strategic conversations should be conducted, and it did not involve conference rooms or formal presentations.
He believed in restaurants.
Not as a reward or a luxury, but as a working environment. A good restaurant, he explained, changed the quality of thinking. It removed the defensive posture that people brought to office meetings. It created space for longer, more open conversations. And it provided, in the tablecloth and the napkins, a perfectly adequate surface for drawing diagrams and writing down ideas as they emerged.
He would arrive at lunch with no agenda and leave several hours later having filled every available napkin and significant portions of the tablecloth with architecture diagrams, decision trees, and strategic priorities. When the tablecloth ran out of space, he would simply continue onto the next available surface and, when the meal was done, buy it from the restaurant.
The first time this happened I was mortified. He sent me to explain to the waiter that we needed to purchase the tablecloth, which had become, in the course of the afternoon, an important business strategy document. The waiter was bemused. The restaurant owner, once the situation was explained, was entirely accommodating and possibly rather pleased.
My boss was unapologetic. A good idea, he said, does not stop being a good idea because it is written on linen rather than paper. And a convention about tablecloth usage should never be allowed to interrupt a train of thought worth following.
I learned more about business in those restaurant sessions than in any formal training I have received before or since.
The Decision
The outcome of our planning was clear: the UK operation needed its own email infrastructure, built properly, on a platform that could grow with the organisation.
The savings from the Novell migration had freed up budget. My boss proposed directing it toward Microsoft Exchange Server — at the time, a genuinely modern platform that integrated tightly with Windows NT and offered something CCMail never had: reliable, fast, always-on messaging that did not require a phone call to confirm delivery.
The condition was that I would do it properly. That meant becoming certified. He proposed a six-week intensive course, full-time bootcamp training, MCSE certification with an Exchange specialisation, company funded, company time. If I passed the exams and successfully rolled out Exchange and Outlook across the entire UK operation, there would be a pay rise at the end of it.
It was, simultaneously, a significant vote of confidence and a very clear set of expectations.
I agreed without hesitation. That is how I became a Microsoft Certified Systems Engineer (MCSE).
What Exchange Actually Changed
The technical migration was the rollout of two Exchange servers, rollout of Microsoft Office Suite and MS-Outlook email client to every PC in the UK, and then cc:mail export and decommissioning afterwards. It all went well. My certification process was demanding but the training was excellent, and arriving at a rollout already understanding the platform deeply made the implementation considerably smoother than it might otherwise have been.
But the interesting part was not the technology or the super smooth rollout. It was what happened to the organisation afterwards.
When email works reliably, when messages arrive in seconds, when the client opens instantly, when you do not need to phone someone to check whether your message has landed, people start using it differently. Email stopped being a supplementary channel and became the primary one. Conversations that had happened by phone, by fax, or by walking across the building began happening in Outlook instead. Information that had lived in people's heads or on paper started being written down and shared. And the speed of the organisation increased. It was true momentum and it changed the culture.
The cultural shift was faster and more complete than I had anticipated. Within weeks of the rollout, the question "have you received my email?" had disappeared almost entirely from the building. People assumed their email had arrived because it had. They replied the same day because response times were now measured in minutes, not in the gaps between synchronisation cycles.
The infrastructure change had unlocked a behavioural change that no amount of training or encouragement could have produced on its own. When the system is reliable, people trust it. When they trust it, they use it. When they use it, the organisation starts to function differently.
And as a result — and most importantly — the pay rise arrived as promised.
What Came Next
My boss, satisfied with the Exchange rollout, handed me the next challenge: full responsibility for the HP-UX K-class and D-class servers running the ERP systems. The enterprise backbone of the operation — the system that the entire manufacturing and logistics workflow depended on.
That is the next story.