New York CTO

Technologists are typically far from superstitious, I am near the top of that list. But there is one thing I am superstitious about... systems failing over holidays or long weekend. Nothing like blissfully leaving the office for more than 2 days off and having it interrupted by an outage call.

One technique I use to ward off these holiday/long weekend outages is to hold a "readiness" meet just before the time off. My experience is that doing such a meeting usually meant nothing bad would happen, or at least if it did the team would be prepared for it.

My team recently did a readiness meeting before the US Thanksgiving holidays, and one of my team came to me early the Monday after and exclaimed "that Voodoo meeting worked, no issues/outages". Hence, the name, which has since stuck and people know what it means if they are invited to a Voodoo meeting. .

Seriously, there is nothing better to get ready than assembling your team together and asking them if the are ready. Are we doing any changes that we should review? Are there any projects launching? Who's going to where should something happen? You may find they go to the desks and double-check systems and changes.

And just as important as a readiness meeting is reaching out to the business to tell them you are "ready", and reiterating incident escalation process. Once we discovered a major issue on a Tuesday after a long weekend, and later determined some end-users had suspected something, but didn't want to bother the IT team on the long weekend.

My message back them:- "Please bother us", its our job.

I have the distinct pleasure of being a mentor in Columbia University's Masters of IT program in continuing education (other posts mentioning Columbia program - http://newyorkcto.blogspot.com/search?q=columbia). My second student just graduated, and I am about to receive my third student in the coming school year. I find it be extremely satisfying to teach a student how to prepare a technology business case, and at the same time find myself reflecting on my own management style, something I am constantly learning and tweaking.

I can't think of a better way for a future CTO or CIO to prepare for the job, and I've given this advice to aspiring CTOs. Check out this recent article on the program: -http://www.informationweek.com/news/management/interviews/showArticle.jh
tml?articleID=210004259

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.

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.

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.

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!.

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.