East coast vs. West Coast

There is no getting away from it in the US, there is the East coast and the West coast, and they are quite different when it comes to CTOs (in my opinion). This gross generalization can be easily shot down, but let me move ahead anyway. West coast CTO = super-tech ex-developer. East coast CTO = less tech but very business focused.

Have I offended anyone yet? Not my intention. My point is that we don't see a lot of transporting of CTOs between the coasts. But I love it every time I get to visit and do business in San Francisco/Silicon Valley. I have the same experience each time, technology rocks there. What I find myself doing is figuring out how to take West coast learnings back to the East coast. There's an easiness/flow to technology development on the West coast which is hard to find back east (along with a little more risk-taking).

As an East coast CTO, you should take every chance you can get to visit the West coast. My first-ever US trip (in the 80s) was to Silicon Valley, and that was my main reason for deciding to move to the US. I "missed" my mark and landed in NYC, but no regrets.

And talking about moving coasts, I am extremely happy to announce that New York got one of its finest back recently, Curtis Brown, the new CTO at Kaplan Test Prep & Admissions (my previous job), formerly CTO at McGraw-Hill/CTB in Monterey. Curtis is the quintessential New York CTO who combines tech know-how with business-savvy. Kaplan will excel under Curtis, and we New York CTOs welcome him back to "our" coast.

Agile and the social developer

I was talking the other day to a technologist who had made the switch early in his career from software development to infrastructure. I asked him why, his answer:- "I didn't want to spend days not interacting with people".

When I was a software developer, it was a lonesome affair. There was no open source community, just manuals and API docs. I got the occasional check-in from my boss and questions to a sysadmin, but mainly was left alone (and liked it). My response to passers-by as to my well-being was often a grunt, as I maniacally focused on the code on my (green) screen in front of me. But that was in the days before agile development.

Agile development practices require a developer to be social. There's a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction. Even open source development is by its nature social. There's no room for a loner.

One of the reasons I stopped coding and became a manager is because I enjoy social interaction (I've been accused of being a "social animal" :-). I do get a buzz out of an interactive tech meeting with developers, admins or CTO peers. For me, this begs the a/b question:- (a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?

But clearly, an agile developer is a social developer. That's a good thing.

Interim CTO

When a CEO leaves a company, usually the first thing that happens is that the sitting Chairman is appointed as interim CEO. Their job is to steer the company until a full-time CEO is hired.

What do companies do when their CTO leaves? Usually get by without one while they begin the search for a new one. Something that I've experienced recently at both my old and new companies is an Interim (or Transitional) CTO someone to take care of technology until a full-time CTO is found.

An interim CTO doesn't start coding software nor configuring servers. Their job is to provide technology representation for the existing team. Technology teams need an advocate, and can feel completely unrepresented without one. Interim CTOs don't need to come up with a technology strategy, but they do need to mind the store, including shepherding in-play projects, running the budget, and executive communication.

iVillage had an interim CTO when I arrived, and his help has been invaluable to me as I got my head around the extensive technology footprint here. Its made me more effective. I could choose what to focus on first, fully knowing that anything I wasn't focused on was being taken care of by someone else. I recommend a 3 month overlap as ideal.

So, for any company losing their CTO, get an Interim CTO. There are plenty of talented consultants/ex-CTOs out there to help you, use them.

Bloggers beware

As we are now all a part of the brave new world of blogging, I am personally discovering some of the unintended outcomes of a CTO blog.

At my previous company, I started blogging well after I became CTO, and some of my team read it out of curiosity. But now at my new company, the new technology team got the chance to read my blog before I arrived, as did other department members. An experience on my first day in the office was someone stopping me in the hallway, and saying "you must be Jon Williams, I read your blog" (hope you liked it was my first thought).

I also discovered that some the tech team learned I was their new CTO via a blog post (not mine), and not from senior management. Not a desirable outcome, yet not something we can control. After we announced my departure at my previous company, and told our contacts of the change, it seemed someone would ending up blogging about it (and did). Clearly the time when companies controlled how information is passed to their employees is changing.

Recently, a fellow CTO at a smaller company was describing how he uses his public blog to influence his internal company agenda. Making his comments public often has a larger impact on his fellow co-workers than a private email. While that is not my intent in this blog, my writings do certainly reflect my views on technology, representing my thoughts and goals.

We should all by now be familiar with the stories of technology leaders who were fired for blogging about their company's technology detailed plans and architecture. This was my main reason for not starting a blog until 2007, quite a few years after those incidents. But in the same way we all figured out the correct "tone" of email, we've hopefully figured out the right tone, content and context for blogging.

And lastly, to the question I posed to another CTO blogger that "our kids will read all our blogs", he replied "...and stop part way through and say 'Dad, your blog is so boring, its all about technology'". Yikes!.

The Last 21 Days

Many things have a beginning and ending. Projects, computers, vacations, games, school, friends, businesses (sometimes), life, and jobs. Some things have planned endings (vacation, school) and others are random by chance. While there is no shortage of management literature on starting new jobs or the "first 90 days" there seems to be little written about the process of leaving a company, we’ll call this “the last 21 days”.

I am now in the midst of both an ending and a new beginning. After 4 years at Kaplan, I am leaving to join iVillage, a division of NBC Universal. I have had a number of jobs in my career, leaving a company is not new to me, yet significant, none the less.

What are you supposed to do when you end a job? It’s not something we think about when taking a job, and also not something discussed, its mostly taboo. Unless you are a consultant, there is no way to "complete" a job. However, I do believe there are important things you should do, and not do, when leaving. I write this because if you are like me, you will have many conflicting emotions with this period of change, drama and sometimes trauma. Strong loyalties may create feelings of guilt for “abandoning” the company, or feelings of failure to complete a mission may even try to creep into your head. That’s the tricky bit and here are my thoughts:

First, leave a job as smoothly as possible. Someone leaving, especially the CTO, can be unsettling for a technology team, so make it as stable as you can. Write a transition document, think of all the things that may come up in the next 6 months, and pass along as much knowledge as you can to your team.

Second, go out on top. If at all possible, don't leave when things are in bad shape. Make sure you are leaving the team and technology systems in top shape. Think of a movie actor or sports star who stayed in the game just a little too long. How undesirable is that? Much better to leave with a legacy of accomplishments and fond memories. Make a list of accomplishments for yourself, and spend just a little time savouring them and congratulating yourself.

Third, talk about leaving. Don't hang your head in shame. Endings are part of life, and acknowledging them helps us deal with them. Talk about why you are leaving, and talk about conflicts you have about leaving. It’s ok to have regrets of missed future opportunities.

While there is no "completed" status for a job like there is a project, make it is complete as possible. And hopefully this will help you move along to your (my) next endeavor, and will keep your reputation in tact with your former employer. Your reputation should grow stronger with the change as you are the one taking the next big step.

Work and Play?

It used to be that work and play had clear delineations, but not anymore, at least not for me, and I believe not for gen-Yers.

For example, while on a recent Seattle vacation, I (1) had lunch with a couple of CTO buddies (play), (2) visited my company's Seattle location (work) (3) afternoon visit with some in-laws (play). But interestingly the 2 play examples are somewhat work-related as we talked tech (my brother-in-law has a tech startup and I was a beta tester). Add to this the daily stream of emails, of which I responded to the all the simple or time-sensitive ones by days end.

Many companies have policies about what staff can do at work, but do they account for our work & play mix? For instance, wouldn't you rather allow an employee to get some of their personal life done at work (i.e. checking an eBay auction, buying movie tix) and then continue working at their desk rather than them going home? Seems like a no-brainer, yet many company's acceptable use policies say otherwise.

Facebook is a startling example of the mixture of play and work. Most of my facebook friends are business colleagues, we've friended each other to see what its like. But... do my work colleagues really want to know the details of what I did on the weekend? Its right there in my frequent facebook status updates. If I posted that I was sick or frustrated, are they obligated to come find me Monday to see how I am feeling?

This blog is another example. Blogging is not part of my CTO job, yet many of my staff and colleagues read my blog. Is it work or play? It certainly doesn't feel like work, and I do it for enjoyment and self-reflection. But vendors also read my blog to see my views on technology. Which is it?

Workplaces need to start thinking about the intersection of work and play, and how to accommodate employees in this new "always on" world. Google does, and I believe they see huge productivity gains because of it. But there are other simpler ways for companies to support their staff besides chefs and game rooms. First is to acknowledge that the line between work and play is blurry, and then see what happens...

Open source is good for IT

I gave a presentation at OSBC (open source business conference) last week. I don't often speak at conferences, but I have been working on an open source strategy for 4 years and believed that presenting that plan might help other CTOs/CIOs in their open source plans. Two bloggers (Matt Asay and Zack Urlocker) reviewed my presentation at http://www.cnet.com/8301-13505_1-9903582-16.html?tag=head and http://weblog.infoworld.com/openresource/archives/2008/03/kaplan_guiding.html?source=rss .

First, Kaplan was not the only company describing their use of open source. Other included CBS interactive, Paypal, Weather Channel interactive, NY times, Electronic Arts, LA times, Christian Science Monitor. In addition, a full 40% of attendees were IT workers, not open source vendors.

In my presentation, I laid out the case for open source, my 3 step plan deploying open source, my experience with vendors and challenges with open source (good summaries on two blogs linked above). I got a myriad of questions from the audience at the end. Our chief architect, Gautam Guliani, was there to answer as well when we were approached privately after general Q&A.

The most difficult question during general Q&A was from Matt Asay, OSBC organizer and also an open source vendor. He asked me the following:- "If an open source platform is stable and my team experienced with it, would I continue to pay annual support fees?". Unfortunately for the vendors, the answer was "no". It truly is a contradiction because if customers don't pay a vendor, they'll go out of business and their products will not be further developed. Frankly, I don't have a better answer. But that said, IMO, open source is a model that is here to stay. Vendors are diving into it and making money, although nowhere near Microsoft's current profit margins.

Open source is good for IT (the customer), period. I believe it is us, IT customers, who are driving open source adoption. In a way, it reminds me of the music industry, and how digital music was driven not by the big music companies, but by consumers.

My question now is:- What are large software companies like Oracle and Microsoft going to do about it?