Before joining Microsoft over 13 years ago, Iain McDonald spent his time as a professional musician and software development contractor for Northern Telecom in Australia.

These days he still jams and admits he owns too many guitars, but he’s also the director of one of Microsoft’s important software projects, Windows Server Group. After working his way through the ranks at the software giant, McDonald now overlooks the Windows Server release planning, delivery, and program management.

Builder AU caught up with McDonald briefly before TechEd 2005 to talk about the future of Microsoft’s platforms.

Builder AU: As a bit of a background for our readers, what is it
that you do
day-to-day at Microsoft?


I go to meetings and try not to get caught being a drongo.
Okay, this is serious isn’t it? I run program management for Windows
Server — mainly that means I own the longer term direction, release
framework, and content of future releases of Windows Server. I also have
development of a few areas reporting to me, my favourite being Terminal
Server.


Many might not know that you are also an Aussie. How did you end up at
Redmond?


I started in Microsoft in Australia in 1991 answering the phones in
Product Support. I had a bunch of experience with e-mail before coming
to Microsoft (mainly from my time with NorTel) — Telstra had just
decided they wanted to roll out MS Mail and I was the Microsoft point
person for the technical side of that.

It turned out we did a bunch of
stuff in Australia that no one in the world had done and they asked me to
come to the US. I was one the original three who were named “escalation
engineer” — the top level of support people — I think there are about
2000 of them now.

Anyway, I realised I moved half-way around the world to
be two miles from the centre of our universe and after a year or so I joined
the development team for what became Exchange Server. I did a bunch of
stuff on that — owned connectivity, the admin story for a while, was
project manager for 5.0 & 5.5 — my last year I worked on OWA — the
thing that ended up being the original application for what’s now known
as AJAX.

At the end of 1998 my eventual boss, Brian Valentine, was asked
to come to Windows 2000 and get it shipped. We’d been around the block a
couple of times and he asked me to be project manager. I was project
director for Windows XP & Windows Server 2003. I moved to this role two
years ago.

Can you tell us more about Outlook Web Access (OWA) and how it was AJAX
before the acronym was born it seems?

For OWA, we had a set of aims (and I say we because it really was a team
effort — some of the guys who were on it back in 1998 are still working
on it and making better). They had to scale it had to have no
client download. IE5 was coming out at the time and it had the support for
dhtml and xml. We actually built two versions of OWA — one for IE5 and another
for IE4 compatible, and included Netscape Navigator at the time. For a
long while
that was our cross-browser story. If there is customer demand, we
generally will look at that as a platform to target — this is exactly
what we did here. Also those browsers now support the building blocks
of what we needed.


I understand you ran the “war room” for the Windows XP release, meaning
any changes had to go through you and your team. Many developers might
be interested in why the .NET runtime was not included in the Windows
XP.


Actually, I ran the war room for Windows 2000. Jack Mayo was the project
manager for XP — he worked for me at the time. Robert Scoble never
included my correction of that on channel9.msdn.com. However, the basic
answer about the CLR 1.0 is it wasn’t ready, and putting two diversely run
projects
together can cause mayhem. It wasn’t worth doing that for what was a 1.0
CLR at the time.


Being a leader on such important projects at Microsoft do you have a
golden rule or tip for project leaders in Australia?


I have two. First is no one wants to work hard for people they can’t
trust. I am honest — sometimes brutally — but at least people know I am
not gaming them. The second is learn to manage your time — if you are
fifteen minutes late everywhere, you shouldn’t wonder why your projects are
late. I am a freak on this now. But it is also very liberating — I have
gone from being someone who was in 80 hours a week to averaging around
52.


I understand the next version of Windows Server will be Windows Server
2007 after Windows Vista is released. Can you shed some light on some of

the server-side features you are currently looking at/excited about?

First off, naming is not decided — let’s just call it Longhorn
Server. Second, we have some great stuff coming out with an interim
release later this year called Windows Server 2003 R2 — that includes
some great enabling stuff for branches, stuff to make storage
management much easier and a set of stuff to make Web single sign-on a
reality. In Longhorn, we have IIS7 which is an awesome release, Indigo
and some killer work on Terminal Server.



Will the WinFS file system be included in Longhorn Server 2007 (or
whatever it might be called)?


Nope.

Why not?

It just wasn’t ready — I believe it is an awesome piece of
technology that will radically change the way people deal with their
‘stuff’. We still have investment and it will release, but we’re much
better off taking a slow burn approach rather than forcing it to change
the world on day one.

It seems Microsoft’s operating systems are having longer and longer
release cycles. Why is this the case?


We needed a reset on process and the ways we were doing things.
Trying to change the axles of your car moving down the road is not a
smart thing to do. We won’t have this sort of gap again. Also the gap
between Windows Server 03 and R2 is actually the shortest update of a
release we’ve done.


What words of advice have you given Sven Hallauer who is now in the “war
room” for Windows Vista?


I meet with Sven all the time — the piece of advice I wish he’d
listen to is to stop listening to that bad 80s heavy metal. We spend
time going over scenarios, review things that happened to make sure the
best result happens in future situations and look at the projects
trajectory.