New York CTO

Started at Experian CheetahMail

2012-01-12T00:49:00.001-05:00

I started this week as CTO of Experian CheetahMail, an industry-leading email marketing provider of Experian Marketing Services, a division of Experian Group Ltd. (LSE:EXPN).

I am very excited to be joining a large software-as-a-service company, CheetahMail was started in New York City in 1998 and a dot-com success story. I look forward to combining my past corporate CTO experience with my recent start-up/online experience to help CheetahMail be a lead-edge user of technology for the benefit of our global customers.

Common name...a curse in online profiles

2011-12-20T12:47:00.000-05:00

Having a common name can be quite tricky online, and takes advanced planning to make sure you dont get left with a bad choice for username. As 'Jon Williams', I try to be the first one claiming 'jonwilliams' in any new online system.

In the 90s and early 2000s when the online population was smaller, I was always successful. I got jonwilliams (at) yahoo.com, email.com, mail.com , excite.com and many other online accounts. I also claimed jonwilliams.com domain (which I dont use but own). But as the online population grew, my hit rate dropped. I missed jonwilliams (at) gmail.com and jonwilliams on Facebook, but I did get jonwilliams on twitter. On linkedin, I had to take jonwill, but no big deal as it only shows up in my public profile link - www.linkedin.com/in/jonwill . Since so many new online services become available weekly, I frequently find that jonwilliams is taken, most recently, jonwilliams on about.me . If about.me takes off, then I'll have to compromise with punctuation or numbers in my name!

Clearly, a single sign-on solution would solve this, but we still seem to be far away from this. Microsoft Passport was a colossal failure. Facebook has done a successful job of single sign-on, but I am not comfortable using that for accounts that may have my credit card. Google may become a standard here, but then I will be jonaussie (at) gmail.com everywhere.

I have some friends with unique single word name handles, like glemak or r0ml, but for me this would feel like I have decided to rename myself to sound like a new start-up (like jonio or jonwillr?). I feel sure this multiple account dilema will go away in the distant future, but for now, I'll keep claiming jonwilliams whenever I can!

... and my apologies to all the other Jon Williams's out there, I feel your pain.

Switched from Blackberry to Droid Pro

2010-12-17T16:37:00.002-05:00

I've been using Droid Pro (Verizon) for one week now, having ditched my Blackberry after 9 loyal years as a thumb user. I was a Blackberry power user, and I have been waiting years for a device like the Droid Pro because I must have a physical, usable, tactile keyboard. It was difficult not to get an iPhone, watching other developers and CTOs enjoy them, but in the end I decided that the iPhone is just not a business email device.

My verdict is... Droid Pro beats Blackberry. I am still getting past some significant keyboard differences, see below. A number of journalists have written reviews comparing the two devices, but with so many smart-phone devices available now, it wasn't really that useful to a long-time Blackberry user like myself. Here is my review (in bullet form)...

Pros

Much better notification controls than Blackberry, can configure both sound and vibration for different apps
Getting to phone, gmail, yahoo mail, text messaging, calendar, and much easier than Blackberry
Keyboard is almost on par, with one major exception (see 'Cons')
Screen timeout, controls, off in pocket all work extremely well. Only bug is screen sometimes flips between portrait/landscape when first coming our of pocket and activating
Apps work fantastic, very much like iPhone (I know, IPhone nailed this years ago). My Blackberry 8300 SUCKED at this, and probably always will
In general, seems highly configurable as a phone and apps.
LOVE Verizon, always works for me in the NYC area and when traveling

Cons

MAJOR Keyboard issue - When hitting keys in top qwerty row, I frequently also hit touch screen command with my fat thumbs (menu/home/back/search), which jumps out of the app I am typing into. Took me a few days to figure out what was happening. Now that I am watchful, happening less, but needs resolution
MINOR keyboard issue - No capital letter on key hold-down, must hit shift (I often used this feature on Blackberry)
Battery runs out before end of day. I have 2 chargers, one at work and one at home
Reading email always seems to be an extra click away, but getting used to it
Contacts are a little slower (I have over a thousand), not quite as easy as Blackberry, but getting used to it

Things I haven't yet figured out

I like notifications (drag top down to see what's new since last use, email, apps, etc), but haven't quite figured out how best to use
How to easily take multiple notes/files? (on Blackberry, was Notes function)
Different apps for same function (i.e. text messaging), always prompts me for which one on action, annoying and caused me deinstall 2nd text message app I was testing
Allows me to send text messages to non-mobile phone numbers, why? It's just stupid.
No easy way to show unread emails in gmail or yahoo mail

The Droid Pro is definitely a learning experience, but after just one short week, I am hooked.

What is "Open"?

2010-01-28T09:34:00.003-05:00

I am a huge advocate of open source software, and now that I am CTO at an open textbook company, I am pondering the question "What is open?". Let me use the moniker "open product" for covering open source software and open textbooks (and if anyone has a better term, please let me know!).

Some criteria for an open product:-
1) A version of product available at no cost
2) A company developing an open product needs a revenue stream to support product development (in what manner those revenues are derived can vary widely)
3) Product needs to be remixable (in technology parlance, "mashable"), allowing for an even better product or use of product

As an open source expert once told me, "without revenue, there is no open source". I believe this applies to all open products.

Many, many products meet the above criteria for "open", let me pick a few:-
- Linux
- Google search
- Flat World Knowledge open textbooks

Not to say Flat World Knowledge open textbooks are in the same league as Linux and Google, but what's interesting is that each of these products provides different revenue streams. Redhat makes revenue by providing support to enterprise Linux users. Additionally, other companies like HP make revenue using Linux on their hardware (HP has claimed that open source software has accounted for billions in indirect, additional revenue sales). Google makes revenue selling keyword and ad placement inside their search results. Of all the open products, in my opinion Google has made the most significant revenue, and interestingly using that revenue to support other open products (i.e. Google docs, email, maps, etc.), which in turn can drive additional revenue.

At Flat World Knowledge, our revenue stream is selling print-on-demand textbooks in addition to our no cost online textbooks. We also sell additional material useful for students, including audio study guides, flash cards and quizzes.

In open source software, you get the "source code", which itself is changable and remixable (depending on creative commons licensing terms). At Flat World Knowledge, our open textbooks are "customizable" (i.e. changable) by educators who adopt our textbooks. They can move chapters and sections around, add anotations, and in the future do many other customizations with our open textbooks. It really is quite amazing how open products have really changed they way products are developed and used, with many, many more changes to come!

With new technology, the tech community at large looks for a moniker to understand and grab on for new concepts. Recent ones include "web 2.0", "cloud computing", and "NoSQL". I wonder what is the best moniker for covering open source software, open textbooks, open courseware, and other "open" things as a group? What about "open product"? I would like to hear from others if this works for the category, or if they have or have heard of better terms. Clearly, this is a space of growing interest, and we will benefit from have a term to describe this new concept wider than just open source software.

Started today at Flat World Knowledge

2010-01-04T22:22:00.003-05:00

I started today as CTO at Flat World Knowledge, a publisher of open-source college text books (a good article describing the model here). It's very exciting to join a start-up and be in the education industry. I also like its similarities to the open source software industry.

While I've been on the corporate route since 2001, I've spent most of my career at small companies. I am really looking forward to the scrappiness and nimbleness of small. While I will be crazy busy, hoping I can regain my blogging activity.

How to choose between a Mac and a PC?

2009-11-04T13:42:00.003-05:00

Simple. Is price the major factor in your purchase decision?

YES -> buy a PC
NO-> buy a Mac

Apologies to anyone who was expecting more. FYI, six months ago I purchased a MacBookPro, it had been 20 years since I my last Mac.

Is cloud computing ready?

2009-10-28T16:16:00.004-04:00

I recently read Infoworld's coverage of Cloud Computing (link here). I think the description is overly complex, futuristic and not clear. The cloud is too new to bed considered as a stack. Let me try to simplify the cloud.

IMO, there are 3 types of cloud services:-
1) SaaS (i.e. Salesforce.com, email outsourced, etc.)
2) Web services (i.e. google maps, facebook connect, XML APIs, ProgrammableWeb, etc.)
3) Infrastructure (i.e. Amazon EC2). This is what I think of when I say "the cloud"

SaaS is relatively easy, either do it or don't, depending on whether SaaS product provides the features you need. Web services is also easy, really just a web API. (NOTE: I am making the assumption that security issues in the cloud meet appropriate standards for you applications. This is different in different industries and applications).

Infrastructure is hard. The main barrier is with existing applications that are two or more years old, and not cloud compatible. I've not seen nor heard of any CTOs moving an existing application to the cloud. I've only seen it done for new application frameworks which are cloud-friendly, typically PHP, Ruby-On-Rails and other open source frameworks. Many startups are using these open source frameworks and the cloud for infrastructure, and having great success.

The other "unspoken" barrier is that deploying in the cloud invalidates existing corporate data center investments. Oops! You would think a private cloud would solve this investment dilemma, but I have not seen large corporations move this way. I was completely surprised when I discovered that most very large corporations have no intentions of building a private cloud.

Question: how is a CTO to move to the cloud?
Answer: by replacing existing application with a brand-new application which is cloud-friendly

This is tough, who has time, budget or inclination to completely replace existing applications? This is way harder than internet-enabling applications, which CTOs have been doing or completed in the last 5+ years. How long will it take for us to completely replace all our application frameworks?

In the meantime, we'll continue to watch with envy as startups make full use of the cloud.

Kindle 2 Review

2009-06-01T15:46:00.002-04:00

I acquired a Kindle 2 a few months ago, and had been using it on my daily train commute. I spend 1st hour reading NY Times, and 2nd hour reading blogs and book samples. Having fun with it, and I am almost ready to cancel my NY times print subscription.

What I like:-
- It’s .3 inches thin, and very style-ly. Has that iPod/iPhone/Palm coolness feel to hold and touch
- Screen is easy to read in all but low light, no eye strain
- All buttons and controls are excellent from physical/mechanical perspective (see "don’t like" below on navigation)
- Power lasts a week, whereas iPod doesn't, although I find myself turning off wireless after daily NY times download, which triples battery time
- Wireless connectivity always works. Full books download in 60 seconds after purchase
- Daily subscription downloads (NY Times, Newsweek, Blogs) happens automatically
- Pictures in articles make NY Times feel like the NY Times. Has a Table of Contents (TOC) for NY Times, easy to browse around
- 14 day free trials of periodicals and first chapter free samples of books. Love this!
- Saving my place in what I read
- Looking up words in dictionary automatically (using this when reading bed-time stories to my son)
- Shopping for books on Amazon store works very well. Auto connected to my Amazon account
- Emailing documents to myself my 10 cents is good (they will be very long documents), although this can be done for free using USB cable to PC
- Seems to bounce well when dropped occasionally

What I don’t like
- Navigation is ok, but not intuitive like the iPod. Needs learning (i.e. difference between back and previous buttons)
- Almost every person in the office whom I demoed to thought it was touch screen for navigation
- Comes with no physical cover, what about just a cheap one?
- $15 for NY times monthly subscription? What about ½ price for existing print subscribers
- Paying monthly fee for blog subscriptions (basically subsidizing free wireless, which Amazon pays)
- Can't have automatic search against NY times (i.e. basketball, Australia, Drupal), has to be manual
- Can't tell which sections of NY times I’ve read, and which I haven’t
- No NY times crossword or KenKen (plus side is I spend more time reading)
- Article clippings lose all formatting, its like Unix (i.e. it just copied text appended to one long file of clippings)
- I don’t like the text-to-speech in general, but that’s just me.
- Cant read reviews of books in store, only overall rating
- I have been unsure about using it on subway.

UPDATE: Went to buy Harry Potter, Book 7 for recent overseas trip and was not available. And I thought initially that search was broken. Same experience as searching for Beatles in iTunes store. Had to carry heavy Harry Potter book 7 on plane, so that soured me a bit on Kindle, but guessing I will get over it.

Voodoo meetings

2008-12-17T19:04:00.000-05:00

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.

Grad school for future CTOs

2008-08-20T20:04:00.001-04:00

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

East coast vs. West Coast

2008-06-16T08:32:00.003-04:00

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

2008-06-11T20:08:00.001-04:00

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

2008-06-06T18:07:00.000-04:00

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

2008-05-06T21:18:00.000-04:00

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

2008-04-17T09:54:00.002-04:00

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?

2008-04-14T19:33:00.001-04:00

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

2008-04-02T19:18:00.006-04:00

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?

The wisdom of herds

2008-03-21T18:27:00.001-04:00

In evaluating technologies, it can often be a struggle to compare competing products. When done diligently, you will probably use a product comparison matrix with weighted scoring. By the way, allow yourself many weeks to collect and evaluate all of the data. And if other people are involved, then also expect lots of meeting to argue pros and cons. And if you also want to do a test drive, there's more time gone. And you haven't built a darned thing yet!

There is another way, but unfortunately it is not always available to us. This other way is:- "What do other people choose?". Why spend time evaluating and/or testing a product when others have done it? This was, in fact, a strong arm technique used by IBM sales in the 80s. The argument was "No one ever got fired for choosing IBM". It actually worked, for a while.

Now, I am not suggesting that this is the hard and fast way to pick a technology, what if the technology is too new?. Rather, use the herd test as a primer before you start doing your own analysis. The results will at least tell you something. I recently heard that 99% of non-profit CIOs chose Windows XP over Vista. Now, that tells me a lot!

Finding out what others are doing before you get started on a lengthy evaluation reminds of a technique I learned in Fire fighting school (I am a volunteer fire fighter). When arriving at a fire scene, after getting hoses charged with water and ready, is to gain entry to the premises, often through the front door. We carry heavy tools to do this, usually an axe and a halogan. But before using these powerful tools on the door, try the handle first to see if it opens :-)

Search as a utility

2008-03-12T20:41:00.001-04:00

We were discussing search at a recent NY CTO club meeting, and a thought occurred to me (as it frequently does in these meetings):- Is search a utility? Meaning, is search a plug-in function and not something to be developed by the tech team.

Every system we build has a search function built into it, usually hand-crafted (proprietary). Why? When I programmed years ago, every system had a screen-writer, which updated the characters and pixels on the screen. But no more, this is now a utility provided by the operating system. It would be crazy to do otherwise. I have plenty of other examples (showing my age!).

So, why isn't search just "available", like google desktop? Why aren't searches in different systems more effective? Why doesn't every search return results in "relevance" order? Why don't some systems have a decent search? Why is search completely different in every system (ever tried MS Outlook search)? Why can't searches be combined across systems?

Search on the internet, whether it be google, youtube, facebook, amazon, ebay, or linkedin, is solved for me, I always find what I need. And I believe the same is true for most consumers. But why not in the enterprise? Seems like a solution waiting to happen....

Effective post-mortems

2008-02-26T21:24:00.001-05:00

One of my tasks as a CTO is running post-mortem meetings after we have an incident or outage. This is an extremely important step toward making progress in system stability and performance. Teams that don't do post-mortems miss the opportunity to get ahead of system issues.

Post-mortem meetings take some finessing, they can easily turn into a blame-game, or he-said she-said. So let me layout how I run post-mortem meetings, and how that makes them most effective.

First, important rules for post-mortems:-
1) Timely to issue (next day is best)
2) All relevant members present (no meeting if someone is missing)
3) Impartial moderator
4) Empty whiteboard to describe incident/issue
5) There is no blame

It is critically important to have "No blame", as you will make no progress otherwise. You need to acknowledge that everyone is working hard, systems can fail and its nobody's fault, and that openly discussing the issues together is the best road to ultimate resolution and system growth.

Now, even if your team knows "no blame", they will probably still be on edge at the start of the meeting. Its natural, failing systems create pressure. The team may also be avoiding dealing with the issue, hoping it will go away, and you may have to bring them back into it. What I find in post-mortems is that teams try too quickly to get to a solution. Don't let them, instead have them focus on a timeline of events.

I've found that starting the meeting with a chronology of events is extremely effective. I ask the team "what happened", and "when", and make them be exact about the when (i.e. 5:14pm), and I transcribe it all to the whiteboard. We include communications and hand-offs in the timeline, and any other information we collected at the time or gleaned later from system logs. Something about the focus on an exact time-line gets everyone to focus as a team. Maybe its because it turns us into detectives examining someone elses problem, not ours (if anyone has a better theory as to why, let me know).

After an hour, we usually have a list of immediate, medium, and long-term actions to take to remedy the issue. From that, the candidate cause/solution usually stands out, and we make sure we have alternate solutions should our candidate be wrong. These are captured on the whiteboard, and we make sure have both mitigations and solutions (making a problem go away is sometimes as good as fixing it).

Email wrong-number

2008-02-15T18:58:00.001-05:00

Sometimes technology can have significant and unintended cultural impacts. Email in its infancy was a minefield, in that we never realized it was an inappropriate (and one-sided) tool for expressing emotions. It took us a while, but we finally taught ourselves to reread and pause before hitting the send button. In Japanese, there is a word for "unsay" to take something back, but alas not in English, nor is there a reliable unsend in email.

I've been using a Blackberry for phone and email for a while, and I've noticed an interesting phenomenon. I will call it the "Friendly wrong number". I meant to call Wendy A, but instead called Wendy B, since I dialed from my email address book and they were adjacent. "Hi, Wendy?" "Yes, who's this?" "Its Jon" "Jon? Oh, we haven't spoken for a few years, You still working at...?". Damn, wrong Wendy. But here's the kicker. I know Wendy and can't just say sorry, wrong number. This could get dicey if your boss is "Jamie B", and your best buddy is "Jamie C".

A variation is the call-back from someone you just spoke to, but by mistake. Some new phone feature must be causing that, I am guessing. Another variation is in email, the dreaded auto-fill feature in Outlook.

This makes me wonder what unintended future impacts technology will have. Many of my LinkedIn contacts have photos, and it won't be long before they also show on phone and email messages on my Blackberry. Will the prevalence of GPS maps make us lose our orientation, and we'll need to carry compasses with us where ever we go (Compass, what's a compass?). I guess we'll find out.

Worthless processes

2008-02-13T19:36:00.001-05:00

When reviewing a write-up or new process/project proposal, a filter that I will apply is "Does this make a difference?".

Let's say one of your team was asked to write up a plan for "managing execution risk", and they wrote a document describing a process for doing this. After you read the document, you decide that while it all makes logical sense, it really will not make a difference. For example, tracking how many lines of code are written each day makes no difference. Who cares? Its business outcomes that matter.

As a CTO, it is your job recognize tasks that don't make a difference, and tell your team that they can stop doing. If something is worthless, say so. Or go one step further, and ask your team to tell you tasks they believe are not useful or optimal. Think of it as spring cleaning. Some tasks are not negiotable and are in fact important for compliance reasons (ie Sarbanes Oxley). But if its internal driven, reexamine it. Our teams are so busy, they'll appreciate the time savings.

So, what processes/tasks are your team doing that you can throw away?

Birds of a Feather

2008-01-17T20:38:00.001-05:00

One of my most rewarding experiences is spending time with other CTOs. Who else knows what its like to do what you do? Nothing like hanging out over chinese food and a few beers with like-minded colleagues that I trust.

Earlier in my career, I felt competitive with my peers, both at work and outside. I felt that it was an "either/or" proposition, either I succeeded/got promoted, or they did. I was comparing myself to them. Eventually I realized that my success (and others) was independent of anyone else. If I was successful, I would be rewarded, regardless of anyone else.

Now I am realizing that younger technology managers I've watched over the years are joining our peer network, and its great to see them advancing as I did. It's such a pleasure to have them as peers, and to see them grow into their leadership roles.

One thing I always experience from peers is "have you thought about...". Its great because (1) I trust and respect their views and, (2) it challenges my thinking on something I hadn't considered. Reminds me of my high school days with a great teacher when I would have a break-through epiphany on a complex concept. There is always something to be learned from your peers.

Technology around the globe

2007-12-10T19:03:00.001-05:00

David Goodman, CTO of International Rescue Committee (http://www.theirc.org) blogged about his recent trip to Africa, where he spent time in Kenyan and Ethopian refugee camps and reviewing technology needs (http://ctoinafrica.blogspot.com). One discovery was that the internet band-width was poor, and David's blog got me thinking in general about how technology is different around the world.

I was going to title this posting "global technology", but that implies we use the same technologies around the world, but that's just not true. Yes, there are similarities, but from a CTO's point of view technology management is quite different once you leave the US, whereas I am convinced that managing technology in the 48 continental states is effectively the same.

I am going to skip the obvious differences (currencies, consumer shipping & payment methods, multi-language, multii-byte character sets, telecomm, regulatory issues), and focus on other non-obvious issues relevant to a CTO dealing with technology overseas. Here are just a few:-
1) US companies do more custom/in-house development than other countries
2) No-name PCs are often used, as not all vendors are established in all countries (i.e. Dell recently lost their presence in Israel)
3) Phone text messaging is more prevalent at executive level than Blackberries

Clearly, some differences will change over time as companies adopt US practices. But the point is, you can't just apply best practices from the US overseas. Be careful about decisions like "every application must run in a browser", it won't necessarily work. I believe the best approach is to support local technology management in individual countries/regions, and as a CTO support those individuals. Disagree, or have a different experience? Let me know.

Every CTO should be on Facebook

2007-11-21T16:22:00.001-05:00

Every CTO should be on Facebook. Why? Facebook could well be what applications look and work like in the future. I don't know if Facebook itself will persist, but certainly the ideas behind it will.

By now, I assume most of us are using LinkedIn, and finding it to be a valuable business networking tool. While Plaxo is mimicing LinkedIn, LinkedIn is mimicing Facebook. You can now load your picture in Linkedin. And LinkedIn just added "today", "yesterday", "last week". Guess where that comes from? Facebook.

"Facebook?", you say. But that's mainly kids. I am not saying that you will get a social networking benefit from using Facebook, but you will learn tons about how new social network interfaces are evolving. Facebook follows the same connection rules as Facebook, other members can only connect to if you accept. I have some personal rules for using facebook. First, accepting links/friends only from people I've met and know. And most importantly, I limit myself to 5-10 mins at a time, Facebook can be really addictive and time-consuming.

There are 1,000s of developers (or more) developing applications for Facebook, and you can try all of them out. Facebook is truly a technology marvel., if your not checking out Facebook, you may really be missing something.

Video promise

2007-11-12T18:53:00.001-05:00

Two bigs trends on the web right now are Social Networking and Video. I've been following internet-based video off-and-on, starting when I did some consulting for a CLEC in 1998. I also looked at IP-based video conferencing for international collaboration. It always seemed to me that video was a promise that never delivers; stiff video conferences and postage stamp-sized choppy video were hard to get excited about.

Well, consumer video (like youtube) is changing all that as it takes off, clearly exploding in use. The combination of high-speed internet and the fact that almost all single-shot digital cameras can also shoot and download video clearly helps. Anyone can shoot a video and download it, and then have youtube or similar deliver it at no cost. Google search results now frequently include videos.

What crystallized the potential of video for me was my own experience playing the guitar. As I hear a song that I would like to learn to play, I now go to youtube to see how other amateurs guitarists have played it. They've shot themselves close-up, with view of guitar fret board, so you can see what chords and strumming patterns they are playing, verses trying to learn the song from listening to the recording. This has been a completely breakthrough for me on new songs, and has improved my playing immeasurably.

I can't help but imagine that there are thousands of other examples, both personal and business, where simple-shot video can be used as a training, business, sales or help tool. Expect to see video really take off in 2008.

Enterprise Social Computing

2007-11-07T18:15:00.001-05:00

My last blog posting was "The problem with Social Networking", and I should have realized that there were smart people already working on the problem. I quote from my last blog:- "Instead of a social network home page, what I would like to see is the intersection of SOA (service-oriented architecture) and social networking". It appears the solution is Enterprise Social Computing.

I attended today the first-ever Alfresco User Conference in New York, Kaplan is a recent customer using their WCM platform. While I could only stay for the morning, I had the privilege of attending Alfresco CTO John Newton's presentation on their product roadmap. He started with a description of his conversion into an open source vendor (John is formerly from Documentum), and how open source is changing market dynamics. John talked about current trends, my favorite quote is "Web 2.0 is right-brain", meaning it is about people, concepts and creativity.

Further into the presentation (and where I got truly excited), he described how enterprise employees use both internal tools like email, MS office, intranet, CRM, etc, and external tools like google search, linkedin, wikipedia, google maps, etc to perform their jobs, and that these tools should be integrated together in an Enterprise Social Computing platform. Yes!!

John went on to describe what enterprises needed:- Facebook-in-a-box. He described how Alfresco had integrated itself into the Facebook api in 3 days, and productized the results in 3 weeks. This was music to my ears, and exactly along the lines of what I believe to be the right solution for corporations.

Enough of facebook, time for me to get some of that facebook-in-a-box (or linkedin-in-a-box) John was talking about. Maybe email will finally start to go the way of the fax and memo?

The problem with Social Networking

2007-11-05T19:15:00.000-05:00

Social networking is huge right now, both in usage and press attention. But I look to history to see what the outcome might be. Remember the AOL/Compuserve/Prodigy (and others) battle? How about the home page battle between Yahoo, Excite, Lycos, Infoseek, AOL?

I believe that the competition to be our social network of choice is flawed. Facebook, Myspace, LinkedIn, Plaxo, Flickr, Youtube and others (including small niche communities) all want us to picK them as our single destination, just as we singularly use email, Google search, iTunes and Amazon. Problem is that I just don't have time to check pages on many different communities.

Instead of a social network home page, what I would like to see is the intersection of SOA (service-oriented architecture) and social networking, where I could have my own home page that shows me all my friends/colleagues from all sources. Think of this as a kind of newsreader for social networking. Until this happens, I will spend most of my time on LinkedIn (for work) and occasionally Facebook and Myspace to check out my friends/contacts.

I still believe that the workplace benefits of social networking has yet to hit corporations, and I haven't yet found a compelling story (beyond the US Army) to taut as a shining example. I am still losing the argument of "it just wastes more time", and I can't prove that it will displace email usage to improve business productivity.

But social networking is where web 2.0 technology is focusing, and is not going away anytime soon, so if your not staying current with it, you may miss the boat.

GoogleDocs and IT

2007-10-17T19:20:00.001-04:00

As I ponder the relevance of Web 2.0 and social networking on the corporate work-force, I believe they could indeed have a profound impact.

Today, the most-used technology tools we've provided our employees are (1) email (2) word/excel/powerpoint. I classify these tools as "self-help", meaning users don't need IT's help to use them. The biggest downside to word/excel is that they are single-user; anti-social, if you will. I will describe email as semi-social, as control/collaboration still resides in each individual inbox. Other tools include your company intranet, and if it's like most, its mainly non-collaborative.

The opportunity that IT has is to begin providing what I will call "self-help 2.0" tools, which are collaborative and support the business version of social networking (will someone please come up with a clever name for this?). As I watch staff use GoogleDocs and other similar tools, I find myself thinking I should be providing them with these kinds of tools. If you'll remember, this was a promise of VBscript, embedded in every Microsoft tool. However, Microsoft overlooked that VBscript is a programming language (it even has a debugger!).

My vision is that IT departments start to provide employees with these web 2.0 self-help tools, and allow non-IT staff to effectively start developing their own applications/functions. Why not? Well, we come up against the same issue IT has struggled with when PCs and email were first available:- Control! Technology teams need to consider giving up control in certain areas, which in turn will allow them to focus in on critical apps. Why would any of us bother developing a simple database application for the business? Let them use GoogleDocs, DabbleDB or similar.

I for one am ready to give up control. Are you ready?

Budget Zen

2007-09-26T18:26:00.001-04:00

Many of you, like me, will have recently spent an inordinate amount of time on budgets. Everyone's favorite task, right?

There was a time when I treated budgets as an annoying task to be gotten out of the way, but I had a zen-type breakthrough when I realized that the budget was the tool I could use to influence technology change.

Discussions on technology are most focused during budget time, you have the business's attention as they recognize that their needs and feedback greatly influence your numbers (and consequently their's). Its a good time to bring up new initiatives, new technologies, replacement plans, disaster recovery and new investments.

It also allows you to gauge the appetite for change in technology in the coming year. Some years are big investments years, others steady as she goes. A well-planned budget is the springboard for a productive year of technology projects. Spend your time wisely here, you'll get back to technology soon enough.

Thinking like a product manager

2007-09-21T19:19:00.001-04:00

One difference between CTOs and CIOs is that CTOs focus on customers, in a product manager role (there are many exceptions on either side of the CTO/CIO title).

Product management takes a different type of thinking than IT for internal staff. For an internal user, you effectively control the relationship and service costs. Sure, you negotiate requirements, priorities and timelines, and you allocate charges, but what real choice do your business users have? (For example, they typically can't go buy and install their own laptop). For a customer, either consumer or a business client, it's a completely different story. You are competing for their business, they have choices and viable alternatives. It can be highly competitive to win them over verses your internal users, who are effectively a captured market. And those with sales experience know it hinges on the service that follows the sale. Bad service and sales will follow.

One effective tool I use for internal staff is to approach them as customers (this takes more than just calling them clients!). Meet with them regularly, give them decision-making power, respond immediately to their needs, write down and answer their questions. Treat them with respect and deference, after all, they are the staff making your company work and satisfying your company's client base.

Listen, don't direct. Sympathize, don't scold. Strive for 100% excellence in service.

Giving presentations

2007-09-19T21:04:00.001-04:00

A big part of a CTO's job is making presentations, usually in PowerPoint. Not anything we learned in engineering school, yet an important skill to acquire. Your projects and even your budget may depend on a good presentation.

I have the pleasure of mentoring a Columbia Master's student in how to prepare a business case and present it. This gives me cause to reflect on my own presentation style, what works and what doesn't. I am also lucky to have received professional coaching on presenting and handling Q&A, in my last job when I worked at a healthcare advertising agency.

I have many tips on how to present, but let me discuss two that I believe are missing from most presentations I see, (1) Presenter introduction (2) Humor.

I've seen countless company introductions, but few people intros. When I am sitting through a presentation, I need to buy into the presenter and trust that they are a subject-matter expert, or at least are who they say they are. They need to win me over, period. Since most of us are not Steve Jobs, we need to introduce ourselves. Just one slide, and if you can mention something personal about yourself, all the better. Be revealing (but appropriate), take a risk, your audience will appreciate it.

Add a joke. After all, we are humans, not robots. If the joke is relevant to the material, excellent (but not a requirement). Even better, make it about yourself, or about a common frustration the audience might have. If you are not good at jokes, steal/borrow one. Practice the timing until you get it right. A good friend of mine has a rule that he had to have a slide of a monkey is every presentation, worked like a charm.

Humor can really work for you. Use it for a transition. Find a spot in your presentation where you make a bold claim, and include an intermediary visual of something negative or unfavorable. For example, you are about to claim your system is easy to use, put in a screen shot of a C:\> prompt in DOS, or a picture of user pulling their hair out. It will get your audience to pay attention, and they'll be wondering if another surprise is coming later in the presentation.

Milestone creep

2007-09-14T18:53:00.000-04:00

Technologists like to invent terms that are self-supporting, "scope creep" is a good example as it paints the business owner in a negative light compared to the technology team. (Scope creep means additional requirements for a system beyond what was originally agreed to). Interestingly, consulting companies don't have scope creep, they have "change requests", with dollars attached.

But what about "Milestone creep" (my own invented term)? My definition is simply that milestones get moved out, usually by the technology team. The milestone is not missed, per say, just moved. Many things cause milestones to be missed, including discovery of unknown issues, dependencies, risks, or bugs. (And for those of you thinking it, scope creep can impact milestones :-).

I've noticed that milestones are often missed due to responsiveness and flexibility, something that many technology organizations pride themselves on. You take on new requests and modifications at the drop of a hat, and the team gets sidetracked from the projects at hand.

Ironically, the CIOs who I've experience as the least cooperative, least helpful and least collaborative are the ones that typically hit their milestones. But at what cost?

Agile's weakness - not 3 steps ahead

2007-09-11T20:50:00.001-04:00

After having lunch recently with a vendor leading us through an Agile process, I mentioned what I believe to be a drawback in the process. Agile does not look far ahead of a project. While this clearly has benefits (i.e. Heads-down on current deliverables, no 100+ requirements doc), it can mean the big picture view getting lost.

I recall a panel at Infoworld's CTO forum in 2002, where Kent Beck and Grady Booch argued this exact point. Kent claimed that the Agile (XP at the time) team would come up with a grand architecture, and Grady said it would be half-baked. By the way, this was probably the best panel I've seen at a conference. The moderator took notes on index cards from the audience right from the beginning.

I think that managers need to look 3 moves ahead separately from the Agile process, and then figure out how to share or infuse that thinking with the team, again outside the Agile process. Dare I say best of both worlds? I would be happy to hear contrary opinions or experiences here, and I'll admit I've not researched if there are ani long-term Agile models.

Case for Social Networking

2007-08-16T19:05:00.001-04:00

As a technologist, I first started using Social networks in 1993, on Compuserve (it was not called social networking then). Most technologists have a similar example, like Prodigy or The Well. I am now a regular LinkedIn user, and our technology wiki is indispensible. The benefits to my company are clearly tangible.

It is entirely possible that large companies could significantly benefit from an internal social networking tool (call it a wiki for arguments sake). But how can one explain the benefits to an executive? Its a tough sell.

While I personally believe social networking will revolutionize corporations, I'm not sure I have a sound argument and reasoning. A tool just like Myspace and Facebook for the office? Won't that mean employees wasting countless hours instead of working? What if our employees post incorrect information? Who's going to monitor it?

My argument hinges on:-
1) Wiki is more productive than email
2) Wiki information being self-correcting, like wikipedia

I believe social networking will displace email, in part, as a workplace tool. Conversations in email will move to an intranet wiki, and staff email time will be freed up to spend on a wiki growing a corporate knowledge-base. But will it? How can I prove it? Plus, it may take years for it to happen. This argument also presupposes that email in its current form is often unproductive as a workplace tool, which goes against everything we said to get email adopted in the first place.

And how can I prove that information will self-correct? Wikipedia is not like a company, so proves nothing. If executives believed in "the wisdom of crowds", then crowds would be running companies. And my prototype company examples, Google and IBM, are atypical. If anyone has a better argument that has worked at the executive level, let's hear it.

Thinking in lists

2007-08-10T18:26:00.001-04:00

I am a prolific list maker. It's my tool for collecting tasks &/or needs and tracking them. My lists are not ToDo's, I find that too defeating and overwhelming as I try to get them all done. Instead, these lists are things I am tracking, whether they be bugs, ideas, major projects, date deliverables, meeting points (one list I have is things I want to do before I get old :-)

My list-making came from an early experience, where I wrote down bugs and feature requests/ideas on a list, using pen/paper and numbering them sequentially. I lost the first list after 680, started a new list which I used for years (and regulalrly photocopied as a backup). I stopped in the 16,000s. Now, I think in lists and will sometimes even write emails as a list.

I found the experience very empowering. It allowed me to have an open conversation with any staff/client/executive/team member and record the results, without making any commitments. It allowed me to separate the information gathering from the commitment making. And "Jon's List" began to take on mythical proportions at my company, with every sales rep wanting to take me to lunch.

Again, the key for me was not to think of these items as ToDo's. They were list items which had many different facits. And yes, I crossed them out when done, or "Z'ed" them if no action needed, but it was still not a ToDo list. I can now think beyond lists, and my lists today are much more modest in size, but it's still a critical tool for me.

Commitment to delivery

2007-08-08T20:06:00.001-04:00

Most technology groups are cross-functional with lots of projects to deliver, and find themselves inundated with new requests, status update meetings, change requests, and the like. Given that technology teams can get very busy, its important to make sure a project will drive to conclusion.

If you want a project to stall, one sure way is to have noone on the team committed to delivery. There needs to be one person, just one, who will drive the project to conclusion as obstacles mount. Without this person, the team will sense there a lack of owner (and no reward for outcome), and shift their focus and priorities to other projects.

This is reasonable behavior, and to be expected. After all, your teams are often being asked to do too many things, and need some mechanism for prioritization. The issue is that the project may be important and beneficial, and you'll need to get someone on the team to "own" it.

Make sure all your projects have "owners" on the team, those who'll stake their reputation on getting it delivered.

Plans & People

2007-08-06T18:48:00.001-04:00

(I'm back. My train rides have been preoccupied with Harry Potter, book 7, and I am a slow reader. With that done - no spoilers here - I can get back to blogging).

When I think about what I do as a CTO, what is most importance to me is plans and people. What! Not technology, you say? How can that be? Well, technology is a fundamental skill that any CTO needs, but the members of a CTO's team are masters of technology. CTOs do not need to be the expert technologist in the room. CTOs need to be leaders.

When I was at University, I had no concept of this. As a programmer, I still had no concept of this. As a project manager, plans suddenly seemed important. For me, the CTO realization, that its not the technology, was a slow one, but something I eventually figured out.

When prioritizing my time as a CTO, planning and people are where I put the majority of my time. Without these, there is no technology at an organization. And planning is as much an art as a science. Imagine if as a programmer you were told 3/4s of you code would be thrown away? That's what happens with planning. Yet, it crucial. Simple, but true.

Home technology

2007-07-23T19:12:00.001-04:00

There was a time when computers existed only in the business work-place. The closest thing we had to a computer at home when I was growing up was a Texas Instruments programmable calculator bought in my senior year, yikes!

Do your employees have better technology at home than they have at work? With high-speed cable/DSL internet to the home, you may be fighting an uphill service battle, since your employees may be downgrading their expectations daily. One of the smarter things IT has done is follow a 3-4 year replacement cycle for PCs, since this closes the gap with a new home computer. But if your supporting a remote office with a T1 connection, you may be toast in comparison.

On the other hand, home computers have increased end-user tolerance to technology issues. Everyone has experienced desktop issues first hand, and most probably had a bad customer service experience with a Dell rep in India. Our users seem to now view desktop issues as beyond the control of the IT department. The trend to internet-based business applications also supports this view.

This is no excuse for not providing stellar desktop service, but you should be thinking about what you are being compared and contrasted to.

Meeting Face-to-face

2007-07-20T17:48:00.001-04:00

In this day and age of email and conference calls, we often miss an important tool at work, the face-to-face meeting. (Note: my apologies to anyone for whom this is obvious, but I've found many technologists to miss the obvious before, including myself).

I was in London recently for a series of business meetings, and again realised just how important in-person can be. As we work more and more with our international offices, we immediately jump into email and conference calls with people we've never met. While this is a hard reality of business, I've found that making the effort to meet has incredible benefits and prodcutive outcomes. It also greatly improves future email and phone conversations.

A good friend of mine had an explanation for this. He asserts that our individual relationships, whether business or personal, rely on a visual image of the person. Without that image, we are less related. I haven't done any further research on this, but it feels true as I've seen personal evidence to support it.

While it would be great to have an online visual image of someone, we are probably a long way from this. Just from my experiences with video conferencing, I find it difficult to get an impression of someone I've never met (it does work if I've met them first). Also, there is no online equivalent of going to dinner or having a drink.

The facebook/myspace generation may break through this barrier, but in the meantime, I'll include face-to-face in my business relationships.

Celebrating wins

2007-07-13T19:57:00.001-04:00

With your teams working hard and driving hard to meet deadlines, its important to celebrate wins when they occur. The best kind to celebrate are the ones that have significant impact and visibility for your end users.

Email is a standard way to do this during the ordinary course of business. Collect positive comments from your beta users and managers, and send out an announcement email to business execs explaining the business benefits and comments from their own staff (anonymous is fine). The more enthusiastic the comment, the better (my current favorite "Dancing in the streets").

It's also important to stress that the project was a partnership between technology and a business group, which allows the business to deservedly share in the celebration.

Make sure not to over-use it (weekly is definitely too often), otherwise it will lose its impact. You'll find that your teams will appreciate this public acknowledgement as they dive into their next project.

Lost in Translation

2007-07-10T20:56:00.001-04:00

Apart from my CTO job, I am also a mentor in Columbia University's Masters of IT program in continuing education. A former boss introduced me to Art Langer, who co-runs the program which is novel in that every master's student (fully employed technologist on management track) gets an executive mentor who works with them over 3 semesters on a business presentation of their final thesis. This presentation is grueling, as the students get just 10 mins to make the business case.

Having worked with 2 students prepare for 4 presentations, and having sat as a judge/executive for dozens of others, I've observed a recurring theme for technology presentations to business executives, that is that they get "lost in translation". This is not restricted to students, I've personally experienced this for my own presentations.

Technologists are great thinkers, but frequently don't know how to make their case to non-techies. My favorite student example was 5 mins into a presentation, I asked "do you mean water?", to which the other judges exclaimed the same thought. The presenter had never once said water, even though the proposal was about selling excess water for power generation. Make it simple! Techie's get so complicated and sophisticated so quickly, they leave out the simple explanations.

Here's an idea. Show your next presentation to your aunt, spouse or next-door neighbor, and then ask them these questions:- What is it (ie subject-matter)? What is the proposal or goal? Why? If they can't answer, then your executive audience probably won't either.

Interruptions

2007-07-09T18:57:00.001-04:00

NMI is an acronym for "Non Maskable Interrupt". For those who programmed Apple Macs back in the day, there was a switch that connected between the vents on the side of a Mac. If a new program stopped responding, you would press the NMI switch to open up the Mac (hex?) debugger. On proprietary hardware I worked on, we mimicked this with a plunger button, giving me the sense of power to "detonate" on the frequent times my code went awry.

Do you have an NMI with your staff? Are you approachable and interruptable? Or do you go into an "infinite loop" when in meetings with your team? You need to make sure your team knows you are interruptable, even mid-sentence, and that you will listen (and not be annoyed!).

As a programmer, I used the NMI switch frequently, I clearly wrote a lot of run-away code. It was easy to press the NMI button, since computers never get offended, but not so easy in the real world. The key is to make being interrupted acceptable, and to have a protocol to deal with it (ie defer till later, take offline, etc).

Remember to have your own NMI switch. Trust me, you are going to want to hear what your team has to say when they interrupt you.

Downtime

2007-07-04T20:13:00.000-04:00

I am writing this from my July 4th week's vacation (which explains my lack of posts this week).

It's important that everyone on your team gets the appropriate downtime, a chance to recharge their batteries. There were times in my career where I described myself as 7/24/364 (I took Xmas day off!). In retrospect, my productivity at times waned, and I would have been more productive in general if I had taken a week off a few times a year.

Downtime is important for technologists, especially those who are typically on call 24/7. If your teams don't want to take the time, force them. Schedule time off well in advance so projects and deliverables can be scheduled around vacation time. And downtime is about being ready to jump back into the thick of projects full force, recharged!

Design pattern standards

2007-06-28T20:58:00.001-04:00

</Warning - old coder>One of my first programming jobs was writing code for proprietary hardware. I wrote most of the code after the "bootstrap", excluding a 3rd party 5K operating system (that's 5K memory, not dollars!). I wrote code to write each pixel on the screen, communicate with the keyboard and mouse, talk to server, etc.etc.</End - old coder>

It was a revolution for me when Apple and Microsoft came out with APIs to do this for you. It would be absurd to have a programer today write pixels, keyboard handlers, or operating systems. Yet why are programmers today working on writing code for mailing addresses, or work orders? Why is there no API?

Furthermore, its happening over and over again. How many programmers wrote or debugged code for address handling in the last year? The remedy to this would be a vendor or industry standard, but that's where it gets complicated.

While industry standards for communication (tcp/ip), data (XML), and the internet (HTML and http) have been hugely succesful, standards around commerce (credit cards, addresses, work orders, etc) have mainly failed. Seems we can't agree on scope.

While a single vendor (ie SAP) would solve the problem, most of us are not willing to give control away, both system and budget.

Maybe open source is the holy grail of design pattern standards. Who knows?

How ready are you for disaster recovery

2007-06-27T18:43:00.001-04:00

With some power blackouts in NYC today, my team asked the question "How ready are we for disaster recovery?".

We do Business Continuity Planning (BCP) regularly, but there is nothing like the threat of the real thing to get the team really thinking if their plans are complete. Didn't we just change system X? Isn't system Y already running on backup? What about that new app we launched last month? How will we push latest code release without staging? Didn't Jack just replace Fred since our last DR run-through?

A CTO's job during a disaster recovery (DR) situation is to (1) create a sense of urgency, and (2) communicate to the business. I trust my team's ability to handle the difficult task of recovery once they are put on alert, and I can get out of the way.

I find it useful to treat potential disasters as the real thing, call it an unplanned drill. Ok, so power didn't go out in our NY data center, but what if it had? What if just data lines went down? It's a chance to freeze all project development for an hour or two and have your teams run through scenarios and contingencies.

Don't miss the opportunity to practise Disaster Recovery when the opportunity arises, one day you'll be glad you did.

Balancing old and new

2007-06-26T23:37:00.001-04:00

When you have time to look up from your daily tasks, you find you come across an astonishing amount of new technology. I could easily spend my entire day looking at and researching what's out there, all of it being of potential benefit to my business.

How do you do spend time on the new and still keep focus on the job at hand of supporting your business' existing technology? Google does this by allocating 20% development time for its employees. This is a luxury most of us don't have.

The trick I believe is to quickly focus on how new technology will benefit your business (I.e. How will the iPhone impaxt your business? What impact might virtualization have in your data center? Will a wiki improve your teams productivity?). I recently became entranced by social networks, to which a fellow CTO asked "What are you going to do about it?". My task now is to marry it to a business project and objective.

I'll also strive to figure out how to incorporate the new with what's working with the old. I've heard so many technologists tell me they could do a better job if they throw a system out and rewrote it from scratch. But it's the smart technologists who'll figure out how to integrate the new with the old, maybe evn seemlessly, and eventually be able to phase out the old at the appropriate later time.

Cone of silence

2007-06-26T23:16:00.001-04:00

I used to enjoy watching the 60s TV show "Get Smart", a spoof on secret agents. While there were many gags that stood out, one enduring one was the "Cone of Silence". Taking many physical forms, often absurd, the device's purpose was to keep the conversation private.

A technology manager needs to keep certain conversations private. You need a cone of silence with your team, where they know they can trust you to keep their confidence. This is truly important, as you'll want your reports to share all information with you, regardless of how difficult or sensitive. Sometimes its as a group, sometimes its 1-on-1.

This cone of silence also applies to networking groups, where trusted relationships allow group members to share sensitive information with each other. You only need one member to carelessly share information with a vendor to break this trust. While I belong to a number of social networks, its the trusted ones that I most rely on. I can share real concerns without fear of disclosure or reprocussions.

While Maxwell Smart's cone of silence seemed always to fail, you'll need to make sure your teams and contacts have a working cone of silence with you.

Advice from CTOs - top 10

2007-06-25T07:51:00.001-04:00

I've gotten a lot of good advice from fellow CTOs over the years, and figured I would share a top 10 list (of advice):-

1) Get a coach (Igor Shindel) - having an executive coach has been an extremely valuable tool for me, and I continue to use a coach.
2) It's the people, stupid (Curtis Brown) - it's not about being the brightest technologist in the room, it's about supporting great technologists.
3) Reward and compliment your teams (Dan Woods) - Recognition goes a long way, plus technology teams typically work long and hard, and deserve an extra nod.
4) Bring it on! (David "Yak" Yakimischak) - When systems start to fail, don't cower and hope they go away. Reproduce the problems at will, and then conquer them. Load testing tools are critical here.
5) Make a list (old boss) - During a critical or rare opportunity meeting, make an action list, and email to all participants after meeting. Simple, obvious, yet highly effective.
6) Architecture is people (John Helm) - Have the right people in place and you'll have the right architecture.
7) Good vendor relations (Dan Holewienko) - Vendors are not out to get you (and your budget share). Make good working relations beyond Purchase Orders.
8) Give to get (Kevin Sickles) - Help out other CTOs and technologists freely, it will all come back in time.
9) Network with other CTOs (me - Jon Williams) - It's like having an all-star baseball team at your fingertips, the cummulative knowledge of a network is outstanding. And meet in person as often as possible.
10) Have fun (Chad Dickerson) - Technology is fun, that's why we do it.

Kaizen management meeting

2007-06-22T19:04:00.001-04:00

Would you believe me if I told you that I had a "fun" management meeting? Ha, you say. Impossible. Well, it was fun.

I recently attended a (non-management) Kaizen Agile development meeting with our mixed staff/consulting team (blogged about it previously), and I became intrigued in how engaging and effective it was. Since I was only an observer (not being a team member), I wanted to participate in a kaizen meeting myself. I convinced my technology management team to join me, with the simple goal of having them take agile learnings back to their teams. I had little hope of any management outcomes, but I was dead wrong here.

We started the meeting at 4:30pm on a Friday, 5 mins with postIt notes on whiteboard, 5 mins reviewing good and bad for the week, 5 mins voting on index cards, then rest of time reviewing top cards voted for (see previous blog for meeting format details). It was fun, and incredibly productive. We discussed 6 key management issues from the week that we had voted on, in order of voting. This was one of the rare times I did not set the agenda in my own management meeting! At the end of each discussion, I handed the card to the manager who would follow up on the issue. If we were having these meetings regularly, the card would be brought back to the next meeting.

There were important logistical elements of the meeting that I left out of my previous post:- (1) beer (2) snacks (3) kaizen kit containing postIt notes/cards/markers (missing bottle opener!). What made the meeting fun was that it was like a board game (whiteboard/postIt's/cards/voting), with an element of chance as you don't know which cards will get the most votes.

My team and I enjoyed it, and we had some good outcomes which we'll follow up on. What more can you ask?

How I made the jump to technology manager

2007-06-21T21:34:00.001-04:00

My first experience as a manager was horrible, and I swore I would never be a manager again, convincing myself that lead programmer was the be all and end all.

I eventually made the permanent jump to manager purely by accident. As a lead developer who mainly worked alone coding, I was always tagged along by a Project Manager on client meetings and projects. As we grew, I soon got sent to clients without a PM, and had to assume that role, copying what I had seen the PM do. Not even on-the-job training, more trial by fire. I coded 50% and project managed 50%. I can't say I was great, I stumbled through it, losing one client along the way. But I made it through because I communicated frequently on what was going on, and asked for lots of help when I got stuck.

My next experience was hiring and leading a technology team at my own consulting company. Managing people was way different (for me) than managing projects. I squeaked by getting the job done, but I had no touch for the "soft side" of managing people. In hindsight, I wouldn't have enjoyed working for me!

It wasn't until I got the CTO title that I started realizing that my success was dependent on supporting my team to succeed. I also realized that being a good technologist didn't translate into being a good manager (step 1 in 12 step program?). I started soliciting (and listening to) feedback on what I was like as a manager, from everyone. I made mistakes, slipping back occasionally into my lead programmer ego, but at least I was aware of these mistakes, and able to modify my behavior each time.

When learning as a technologist, I was downloading, practising and mastering new technology (think Trinity in the Matrix just before she pilots a helicopter). A difference between my technology and management experiences is that I learned technology from just a few mentors, but learned management from everywhere and everyone. And I realized management wasn't about becoming a master, but a permanent student!

Note-taking & follow-up.

2007-06-19T18:38:00.001-04:00

In my job I get to formally meet with business staff and executives where the topic of conversation is technology. Typically, these meetings occur only a few times a year, and take the form of an update on what's launched recently, what's up and coming, and then significant Q&A time on what's needed, not working, or simple desired.

I treat these meetings as a unique opportunity to get feedback and requests. I take detailed notes about what is being asked for. While I clearly cannot get everything done, I find these notes critically in letting the business know that I am listening to them. I distribute my itemized notes a week or two after the meeting, follow up on any items that I have immediate answers for. I'll also review my notes 3 months or 6 months out and send further follow-up any issues or systems that have been fixed or deployed, or even just being discussed or considered. I also bring my notes to annual planning meetings as they'll influence priorities and decision-making.

I've gotten a lot of positive feedback from business users and executives that they are not used to getting such follow-up from technology. Their past experiences were frequently that they were not listened to. Interesting, this follow-up does not create the unrealistic expectation that everything will get done, a fear some technologists have (if I write it down, I am committing to it).

Note-taking and follow-up are active listening tools that will get the attention of your user-base, and help you on the road to creating a service-focused technology organization.

Architecture & People

2007-06-18T17:12:00.001-04:00

Architecture in technology is a term bantied about with all sorts of meanings. Some use it for standardization, or innovation, or infrastructure, or platform, or interfaces. Regardless, it's clear to me that architecture is a very important element of successful software development.

My favored definition of architecture is "glue", the stuff that makes different systems work together. I also like "gap" as a description, that when something falls in the gap between two systems, it's architecture.

But architecture really means people working , communicating, designing and working together. CTO John Helm describes architect as "people working together". My focus on architecture is communication, from which comes sound architecture. Are we getting input from all tech leads, is DB team involved, what about ops? It is also key that Architecture leads not "lord over" the development teams. The best architects act as shepherds of technology, and include the development teams in technology architecture exploration and outcome, making it a team effort.

With teams in place collaborating and communicating, you will be on the right track to architecture.

Rules vs Rationales

2007-06-15T18:56:00.001-04:00

In deploying desktop technology, we strive for standardization to make this a managable task. If every employee had a different make of PC, a different version of software, it quickly becomes a desktop management nightmare.

As part of this standardization, IT departments come up with rules / policies, like no email PST files, size limit on email, no IM software (Note: I am not advocating these specific rules). When a user asks for something against policy, they are told "no", often with no explanation. This is where the stereo-typed, difficult IT support persona comes from.

What I prefer to do, in place of quoting policy, is to explain in rational terms the reason behind the rule. We can't support rogue wireless devices plugged into our network because it could breach are security or compromise our network performance. I'll even quote examples of past issues, which is often where the policy comes from in the first place.

The difficult thing about providing a rational reason is that you need to be prepared for an alternate view or argument that shows that the example reason is not at issue (wireless is completely separate from network and therefore poses no risk).

Technology managers need to be careful not to preach policy, but instead engage in rational dialog to reach the desired standardization outcomes.

Another reason why I blog

2007-06-15T11:49:00.001-04:00

Saw this poem on LinkedIn answers, it's represents how I feel about this
blog.

The Bridge Builder

An old man, going a lone highway,

Came, at the evening, cold and gray,

To a chasm, vast, and deep, and wide,

Through which was flowing a sullen tide.

The old man crossed in the twilight dim;

The sullen stream had no fears for him;

But he turned, when safe on the other side,

And built a bridge to span the tide.

"Old man," said a fellow pilgrim, near,

"You are wasting strength with building here;

Your journey will end with the ending day;

You never again must pass this way;

You have crossed the chasm, deep and wide-

Why build you a bridge at the eventide?"

The builder lifted his old gray head:

"Good friend, in the path I have come," he said,

"There followeth after me today,

A youth, whose feet must pass this way.

This chasm, that has been naught to me,

To that fair-haired youth may a pitfall be.

He, too, must cross in the twilight dim;

Good friend, I am building the bridge for him."

- Will Allen Dromgoole (1860 - 1934)

Tivo for conferences

2007-06-14T18:59:00.001-04:00

Tivo has changed the way I watch television, and there are times I wish I had this efficiency tool elsewhere.

My last two posts were (1) vendors (2) conferences, this one is about vendors at conferences. I think promotional videos at conferences are a turn-off, and there I am sitting there with no Tivo. This happened twice recently, and one was not a tech vendor but a large music company which showed a 15 minute promo of their artists. Fifteen minutes of self-glorification. Apple, eat their hearts out.

I've seen many great presentations from vendors at conferences. This happens when they stay away from marketing and discuss trends/roadmaps, or explore new concepts and opportunities. I want to hear how vendors are exploring and making future markets, not about what products they have today (I can get that by visiting their booth, website, or sales rep for that).

Without vendors, there wouldn't be (many) conferences, but vendors need to understand they are on show, and are being judged by the respect they show the audience. Present to our brains, not our budgets.

Vendors are people too

2007-06-13T19:30:00.001-04:00

I was recently discussing vendors with Dan Holewienko, a consultant I trust, who said "vendors are people too". We sometimes forget this, instead treating them as a nameless member of a corporate entity.

Technologists may treat vendors as the enemy, especially when discussing price. Why? Because discussing pricing and terms is a battle, and the vendor is trying to push you into the highest price possible, so fight for price. I don't believe this is the right model. Vendors are business people, you're a business person, do business.

Do give vendors all the information they need to understand your business and your goals. Do share your pricing targets. Do share which other vendors you are talking to. Do share where you are in approval process. Do negotiate. Do give losing vendors your final decision and reasoning.

If you haven't had significant experience negotiating and working with vendors, hire an independent consultant who has.

Working with a vendor is not a transaction. Maintain a relationship with the vendor, touching base at least every 6 months. You don't have to purchase anything to touch base, but you'll be better off when you do.

Conference day-dreaming

2007-06-13T17:16:00.001-04:00

I've been lucky enough to attend a few 1-day conferences recently (last year was a no-conference heads-down year). While I find the hit rate for a good presentation is about 50%, what I value most is taking the opportunity to lift my head out of the day-to-day and think openly about future technology plans.

While the conference content is typically valuable, that's not where I get the most benefit. When a speaker is interesting but not completely engaging (typically good content and poor presentation), I find my mind wondering to my own ideas and plans. Are we planning SOA? Where does Agile fit? What about virtualization? I'll convert what the speaker is saying into my own thoughts, teams and plans. Sometimes it's completely unrelated to the speaker's topic, but triggered by it. I come up with more ideas at conferences than at any other time.

My team gets a lot of spam email from me at conferences, "what about this...". What I am trying to do is engage them in my new thinking. Frankly, a better way to do that is to take them to the conference with you. If you can't do that, then write up your conference notes and share them with your team.

Give yourself a "safe" place away from your day-to-day responsibilities to day-dream about your technology plans.

Testing assumptions

2007-06-13T17:14:00.003-04:00

When I was a computer science major, our available computer lab time was extremely low in my first year. This drove me to come up with the perfect solution in my weekly coding assignments, since I had little time for trial and error. I remember one major assignment where I only compiled twice (one minor mistake), and thought this was perfect. I've since then spent the rest of my career unlearning this training, clearly there is no "perfect".

Like many technologists, I assumed outcomes without fully testing my changes. I see this is over and over again, and I encourage my team to "try it out" or "show me" or "ask". Because developers work in a virtual world, they extrapolate and make assumptions about their code/config changes, its their MO. Because managers work in the real world, they need to check these assumptions. Does your new printer work? Is the new blackberry working same as old? Can you access that directory now? Is date range on that report query what you needed? I have an adage that it doesnt work until it's been observed to be working.

Test-driven development is a great step towards getting developers to test their assumptions, but many businesses could improve with a test-first CTO.

Why Do I Blog?

2007-06-13T17:14:00.001-04:00

I've gotten this question a lot, "Why do I blog?". The simple answer is, "To share my technology management experience with others", but let me expand on that.

In my own career, I found learning new technologies both challenging and rewarding, and I thrived on them. But when it came to management challenges, it was a miserable. I failed consistently, and I believe that I failed because (1) I had no management training, and (2) I had no management mentors (I did have great technology mentors).

What makes a great technologist is very different from what makes a great manager. But over time, through trial and error, I overcame my shortcoming, found some kind mentors, and finally had some break-throughs in management, along with the more infrequent setbacks. One of my break-throughs was soliciting input from my network (and listening) about their management advice and experience.

My goal now is to be able to assist great technologists become great managers, with (hopefully) significantly less pain than I went through. It's not hard (like writing a new operating system or learning a new programming language is hard), but it does require a different approach, a different point of view.

This blog is targeted to technology managers or "would be" managers. I manage every day, and I hope my little insights help you achieve your management goals.

Now crossblogging

2007-06-13T17:10:00.000-04:00

Since I do all my blogging via email, and Blogger supports email (MovableType does not), I am going to continue blogging here, and then crossblog to my Infoworld blog at http://weblog.infoworld.com/ny-cto .

MY BLOG HAS MOVED

2007-06-12T08:15:00.002-04:00

UPDATE Nov 2009: I stopped blogging for Infoworld, this Blog has all my posts. Ignore below.

My blog has moved.

The folks at Infoworld have offered to host my blog, please switch your readers/feeds to :- http://weblog.infoworld.com/ny-cto

(UPDATE: since I do all my blogging via email, and Blogger supports email (MovableType does not), I am going to continue blogging here, and then crossblog to my Infoworld blog at http://weblog.infoworld.com/ny-cto )

Kaizen meets Agile

2007-06-08T18:41:00.001-04:00

I recently sat in on my first ever kaizen meeting (I am learning Agile by observation). The purpose of the meeting was to review the week, a post-mortem of sorts to discuss issues in an open, constructive way. One meeting directive is "Blame has no place in kaizen". This meeting was strikingly different from other meetings I attend.

- Step 1, each team member wrote an action or issue from the week on a postIt note (different colors help), and placed on a whiteboard which was split into Monday to Friday (left to right), happy to sad (top to bottom). This was frenetic as they had only 5 mins, and were dodging each other.
- Step 2, each day was reviewed, both the good and the bad. As this was occuring, members were transfering issues to index cards (a staple of Agile processes). Interestingly, one of the sad postIt notes was "spectator in kaizen meeting", referring to me.
- Step 3, index cards were laid out on table (including some old ones from previous week), a postIt affixed to side of each card, and team members voted which issue they wanted to discuss, having 5 votes each to distribute among cards. Very democratic.
- Step 4, index cards we discussed in detail in voting order until meeting's end (1.5 hours allocated in total). Cards we given to members who would work on issues the following week.

It was really quite amazing. My observations of the meeting were:-
1) Interactive, due to physical components (posting & voting)
2) Successes were acknowledged and celebrated
3) Opportunity to vent
4) Lo-tech (pen & paper)
5) Productive
6) Fun

Fun? Yes, fun. A fun post-mortem. But aren't post-mortems supposed to be serious affairs? Well, this meeting was serious, and productive, and fun.

CTO as translator

2007-06-07T19:27:00.001-04:00

The job of a CTO is to translate technology to business executives. I found a recent excellent example of this, a 4 min video on how a wiki works. I wish I could say I've perfected translation, but frankly its not always easy, and I have my slip-ups. Sometimes I get asked what an acronym means and I've forgotten, but I've probably already erred by including it in the first place.

When I am communicating an issue via email, I try to keep it short, in 3 sections:-
1) What happened - 1 or 2 sentences, mentioning business impact, not just servers/services
2) Next action - usually a now and later, or plan A/plan B
3) Decision needing executive input ($'s, unscheduled maint downtime, project delay, etc).

The key is to keep it short (just the facts), and to reread it with a non-technology eye. Using bullets helps. I'll sometimes run it by a non-technologist first to see if they understand it. Just make sure not to let your executive emails get lost in translation.

The check-in

2007-06-06T21:44:00.001-04:00

We all make assumptions about our communications. We assume that email gets read and understood, reports are reviewed, decisions made. Well, guess what? Executives and managers get hundreds and hundreds of emails a day, and they don't always take action on every email. An issue with email is that it's a one-way dialog. What if the receiver has a question or doesn't really understand the issue, and therefore can't make a decision?

To get past this possible impasse, I use the "check-in", either email or even better, in person. If it's email, I will send a followup to a long or complex or critical email, with simple text asking "does this make sense". I'll also send to mutliple business managers if possible, knowing that not all will respond.

I also do the "walk-around", where I'll walk from office to office to touch base with execs or managers, and simply ask what's up. Did you have any follow-on questions to email X? Any other issues? Email is a simple tool which fails when things get complex, and is never a substitute for a real business discussion.

Until the 20-something execs who use Instant Messenger (IM) take over corporate america, rely on the check-in.

Owning mistakes

2007-06-05T20:53:00.001-04:00

I've made lots of mistakes in my technology career, call them my battle scars. From when I was a junior developer (accidentally typing DEL *.* when I meant DIR *.*), to significant management mis-steps (under-investing in Infrastructure). They've shaped me, and made me a better manager. It's what people mean when they say they are "experienced" (now there's a euphamism!).

One thing I've learned is that making mistakes is a fact of business. It's unavoidable if you are pushing past norms, what we call "stretching". Trying not to make mistakes is not a good strategy, the outcome will be one of conservatism and negativity, and many IT departments are view this way.

I have a few simple rules about mistakes, for both me and my team:-
1) We are all allowed to make mistakes, no blame will be laid
2) Mistakes are an opportunity to learn
3) Get lots of opinions and input to mitigate against mistakes
4) Don't make the same mistake twice
5) Own the mistake

This last one is key, owning mistakes. There is incredible power in saying "we screwed up". Acceptance of mistakes is a key to conquering them. Some of the best leadership moments I've witnessed are around owning mistakes. I know I will follow somene who admits and owns their mistakes, and so will your teams.

Mitigation solves problems

2007-06-04T19:17:00.001-04:00

Technologists love solving problems, that's how we are wired. But not all problems can be resolved, or at least not in a timely manner. Mitigation in technology terms means alternatives for a when a problem occurs, reducing or completely removing business impact. I find mitigation to be an under-used tool.

By my own definition, an outage is a system incident which negatively impacts my business, either staff or customers. If an outage occurs which has no impact, then it was never an outage, and will be reclassified as just an incident (significantly less severe than an outage). A clear example of this is our RAID systems, where a disk fails but the outage has no impact. In this case, the "R" in RAID stands for redundancy. Unfortunately, redundancy across all systems is extremely expensive and complex.

I've often asked my teams not to focus on problem-solving, but instead focus on mitigation. If system X fails, how can we get services back up without fixing the problem? Doing this in advance will create a level of preparedness for the inevitable system issues occur.

There's another artifact of mitigation that's less obvious:- Mitigation takes the pressure off a situation. An outage that has no recourse is high stakes, high pressure, and not the best conditions for you and your team's optimal performance. Mitigation can then become the safety net as the team performs their high-wire act. For me, mitigation solves problem.

The stuck bit

2007-06-01T18:24:00.001-04:00

To follow my last posting on The fuzzy bit, another bug we had on our internally built motherboards were "stuck" bits (similar to stuck pixels on a monitor or flat-screen TV). These bits were much easier to diagnose and discover than a fuzzy bit, but pesky none the less.

Technology teams sometimes get viewed as the harbingers of No when it comes to working with the business. No, we are too busy. No, its too complicated. No, we can't reuse it. No, but you just won't understand why (the all-knowing IT). This comes from technologists being logical, binary engineers. And since saying yes would require knowing all the facts, and how can anyone know all the facts over a first conversation, they say no. They don't really mean no, in fact, they are often open to the idea, but that's not the message they send.

Technologists need to work on how to say "yes", without committing to deliverables in the same breath. Yes, that's a good idea. Yes, its worth further discussion. Yes, your business needs technology innovation. After all, the business sets the agenda, not technology. The answer should always be yes, it's just a matter of how, when, who and where (and how much $). Then your No bit will get unstuck.

The fuzzy bit

2007-05-31T18:54:00.001-04:00

Technologists think in black and white, zeros and ones, yes or no. But management is not all about yes or no. There is a grey area, let's call it the fuzzy bit. (For non-techs, a "bit" is the smallest unit of storage or calculation, and all other elements are comprised of bits. Each of the letters typed here are comprised of 8 or 16 bits, depending on which system you are viewing them from).

When I programmed on proprietary motherboards, we would occasionally come across a fuzzy bit, which oscillated between zero and one. As a programmer, the fuzzy bit caused all sorts of inexplicable errors in my code, but in management, it's an essential tool in the process of decision-making. Why? It promotes discussion and collaboration in reaching a final outcome, either one way or another. Technologists are not always comfortable with this, prefering a known, immediate outcome. But, an outcome squelchs discussion and exploration.

As a programmer, the fuzzy bit cost me countless lost days and all-nighters, and I dreaded encountering it. As a manager, I couldn't live without the fuzzy bit.

Networking - people, not computers

2007-05-30T18:57:00.001-04:00

I am a prolific networker, it comes from my days as a consultant, where my network was my livelyhood. I've shunned the ways of consulting for life as a full-time CTO. But I still network.

Why network? It increases ones knowledge of technology. Don't know the latest Open source CMS tools, or how to scale MySQL, or optimal email backup stategies? Someone in my network knows, and would be happy to share.

I approach networking by doing the first favor. My good friend Kevin Sickles of Sun Microsystems put it best "plant the seeds, you never know where the flowers will grow". So I plant seeds. I don't track who's returned favors and who hasn't, that's not the point. It's having a whole network I can go to with a question when I am in need.

I've recently incorporated networking as I interview senior candidates. I look for past connections, and when a candidate is not a good fit for a position, but a good technologist, I might give them advice, and maintain a connection as they track into their next job. Just because they are not on my team, doesn't mean I can't learn from them, or even recommend them to another CTO. I recently found an excellent PM through a candidate I interviewed but never hired.

My tool of choice for networking is email (was doing this long before LinkedIn). For a connection email, I'll use subject "Ping", "Hey", or "Catchup", and simply ask how are things going. That way if the person is too busy to respond, they'll understand its just a touchpoint and we'll get another chance to connect. I also try to do 2 lunches a week with my network, nothing beats a face-to-face interaction. I roll through my contact list, ping some contacts, suggest lunch with others.

I can't imagine doing my job without my network.

Perception is Reality

2007-05-25T16:25:00.001-04:00

Technology is a service provider to its business at most companies, and its important to get feedback on that service. Its not always easy to do. Either the business doesn't want to tell you the bad stuff, or when they do, you and your team have a hard time hearing it.

I have a saying that helps frame this:- "Perception is Reality". If the business thinks we are providing bad service, then we are, regardless of what we might believe to be the facts. This is a lesson companies know to be true with consumers, yet IT organizations struggle, I believe because they are so enamored with the facts (mainly because we are engineers).

This saying also works in that it shifts focus from whether a team or individual is "wrong" or "bad", and moves focus to the type of service they are providing. A team can be good and provide bad service (and visa versa, although much less common IMO).

Technology teams that focus on service will succeed.

Early management experience

2007-05-24T19:14:00.001-04:00

I had lunch today with a programmer I hired and managed 14 years ago (another excellent LinkedIn outcome). Besides catching up and remembering the rest of the team, I got a view into the type of manager I was 14 years ago, and... I was awful!

Back then I focused on 3 things, technology, technology and technology. There was no "soft side" of management, at that time I thought management was telling people what to do. Luckily, they were a highly talented group of programmers, and as individuals they did some great stuff with the bleeding-edge, latest and greatest technology we were using (I also hadn't yet figured out risk of using new technlogy). But there was no "team", really. People helped each other out, but there was no break-through, what I describe as 1+1=3, when the team creates an outcome that no individual could have even conceived.

In hindsight, it was an opportunity lost, but lesson learned.

Lunch AND Learn

2007-05-23T21:22:00.001-04:00

We have a great program in our technology department that I am quite proud of, called "Lunch AND Learn". We regularly have a team member give a subject-matter expert presentation on a technology topic to the rest of the team. Lunch is provided (pizza), and the goal is to provide a learning opportunity outside of one's normal job skills. The program is the brain-child of Gautam Guliani, our head architect.

We cover a wide variety of topics (the most recent was Word & Outlook Tips & Tricks, the next is Ruby on Rails). I once gave on overview on company executives and the products/departments they are responsible for. We also had one presentation on how to give a presentation, so team members would have the skills needed to present at a future Lunch AND Learn. We quite often have non-tech department staff join us.

The program was previously called "Brown Bags" where attendees brought their own lunch, but we upgraded the program since it was so successful. I can just see the proposal for next year, "Back massage AND learn" :-). Jokes aside, this is a program that will continue to have my full support.

(Update: Gautam shares tips on how to give a good Lunch AND Learn presentation)

Ignore Technology Risk at your peril

2007-05-22T21:09:00.001-04:00

Risk is something I never understood as a developer, optomistic is not a strong enough word to describe my approach. My favorite example was the day I independently decided our windowing system needed a complete rewrite (1988, pre Microsoft Windows 3.0). I announced to my boss that I would work through the night to get it down, and expect resolution in 24 hours. Well, two weeks later I had removed the last major bug (can someone say "whoops"?). If I had been managing by risk, this would have been approached completely differently (I.e. Peer design review, estimate assessment, plan B fail-over plan, business interruption consideration, and the list goes on...).

Managing by risk is asking the question "What could go wrong? What might not work as planned?", predicting that likelyhood, and planning mitigations and contigencies. I will often ask my team to include top 3 risks in project status reports as a mechanism to bring risks to the fore, and believe this to be a best practise. My experience has been that known risks can always be managed, and that unknown (or ignored) risks are the ones that cause grief.

Sharing a risk is itself a mitigation, and also serves the purpose of quantifying and qualifying it. (That idea alone would have saved me 20 all-nighters). Yes, I've ignored risks. Yes, I've had grief. But I've learnt my lesson enough to know that a focus on risk is a key to success.

Kaplan on Myspace

2007-05-22T07:59:00.001-04:00

http://www.myspace.com/kaplan - Make sure to watch the video. Fun stuff!

Is the Blackberry anti-social?

2007-05-21T21:06:00.000-04:00

I checked my Blackberry towards the end of dinner with an overseas colleague, and it was gently suggested this might be anti-social behavior. This sparked an interesting discussion, where I gave my usual pitch as to being more productive and available by checking email constantly. But its truly an interesting question.

Do human interactions need to be exclusive, or can I "double date", so to speak? I get a call from a colleague during a meeting that to can't take, so I email back "what's up?". I can get a request for tech help, and forward it without speaking to anyone, all while attending a kids soccer game or ordering a burger at a diner. I may be fooling myself, but I truly do believe I am more productive because of my Blackberry.

As to the answer to this question, in part this comes down to the expectation of social company. Baby boomer's single-task, and expect undivided attention. GenX/GenY grew up with IM, and accept multitasking.

If your kid looks up from a soccer game, and your typing on your Blackberry, will they say "Dad's multitasking" or not? However, I bet I'll be at more soccer games than the previous generation.

Email - in all shapes and sizes

2007-05-18T18:39:00.001-04:00

In corporate email systems, we have a reasonable set of tools for filtering most email spam, but why is all the rest of my email treated equal? My email comes in all different flavors, yet there is no tool to help distinguish that. It takes my own on-the-fly filtering to do that.

Setting up client-side rule-based filtering can wreak disaster when faulty rules hide critical emails (one case it was from an unhappy client who asumed they were being ignored). So I stay away.

The biggest issue for attempting to apply email filtering rules is context (ie what's important to the reader now). For instance, if one of my kids is sick, then every email from my family is of critical importance, otheriwse it goes into the "after work" queue.

Reading and filtering emails will continue to be a human task.

LinkedIn etiquette

2007-05-16T18:34:00.001-04:00

LinkedIn reached critical mass about 6 months ago, and started to become a useful tool for me (I have 250+ contacts, resulting in a 1MM people network). Someone suggested the links in Google when you search a person was the difference maker. So far I've advertised jobs on my team, hired a programmer, tracked career changes and reconnected with colleagues I've not seen for 15 years. This is enough for me to deem it worth the effort to maintain. I also like that LinkedIn has made frequent changes, each making it easier to track changes in my network.

Just as many young people's online persona is their facebook or myspace page, my online persona is http://www.linkedin.com/in/jonwill - (you'll also find a link to my Myspace and Flickr pages there!)

I have a few simple rules for myself using LinkedIn:-
1) Only connect with people I've met in person face-to-face
2) No vendors unless relationship is stronger than just vendor (same for recruiters)
3) No recommendations for people I currently work with

You'll notice not everyone follows this etiquette (nor is it official policy on linkedin), but it's easy enough not to respond to random invitations. If I know the person, I will give them my reason for not connecting.

Journalism vs Blogging

2007-05-15T22:00:00.001-04:00

The first 10 years of my career was spent working with newspapers and magazines, I've worked closely with journalists and editors (and publishers), and appreciate the work they do. To me, blogging is very different from journalism, but I'm not sure all agree.

Over dinner with Steve Fox, editor-in-chief of Infoworld (http://www.infoworld.com), he argued that many consumers don't make the distinction. He says many people believe journalists are "directed" by advertisers and publishers, as recently shown by the PC World magazine curfuffle. And since television is clearly directed by advertisers (look at product placement on American Idol, for instance), isn't journallism too?

I say no, journalism is an art that will persevere through media change. Blogging is simply opinion, a point of view. Consumers will seek out journalism, not peer blogging.

Or am I wrong, and is blogging the new "reality TV" of journalism? We'll find out soon enough.

Music and my guitar

2007-05-14T19:09:00.001-04:00

(Note: This is not a tech posting) I taught myself to play guitar starting 5 years ago, and I am at the stage where I can learn to play most new songs I hear. Looking up chords on the internet is invaluable here, as is my iPod as I listen to these songs over and over again, pausing, rewinding, etc. I haven't tried lyrics on my iPod yet, I use my Blackberry for that.

Performing and reproducing music has given me a new appreciation for the music I listen to, both past and present. Which songs are simple 4 chords with powerful lyrics, which are complex or subtle, or out of the ordinary format (Beatles seems to have all of the above). It's also trial and error, which songs I "feel" and thus perform verses which songs just don't take when I try them on the guitar.

I've played at 6 open mics so far, and enjoyed them all. I've had my hits and misses, but I am really learning to appreciate the art of the performance of my fellow amateurs. Now when I go see a professional musician, they make it seem so effortless its just incredible, as so much goes into a performance.

While I am still a freshman when it comes to performing at open mics, I have some tips for newbies:-
- Don't stop, pause, say "whoops". Noone knows when you make a mistake unless you tell them.
- Stand-up. That's what the real performers do, and it really helps projection
- Buy the cheapest mic, stand and amp on www.musiciansfriend.com and practise singing into microphone and playing amplified. Really helps with confidence
- Record yourself (tape is fine, I use my Canon SD 600 digital camera), and play it back to hear what you sound like
- Announce song writer and song name before performing each song (else everyone will think you wrote it)
- Banter between first and second song. Connect with audience. "Is everyone having a good time" is an easy ice-breaker

I have to thank my friends at the Circle of Friends Coffeehouse in Pleasantville - http://www.songster.org - for allowing me to learn these lessons while playing to them. And I have a lot more to learn....

Blogging via email - so far...

2007-05-14T18:50:00.001-04:00

As I mentioned in my first ever post, the reason I've started blogging is that I can do it via email from my blackberry during my evening train commute home. This allows me to blog during work "down-time" and between evening emails.

So far, it's working well, with a few caveats:-
1) No spellcheck
2) No pasting URL links
3) Writing a page-full
4) BUG: Font occasionally switches to smaller font size

I will need to retest spellcheck for Blackberry, something I did 12 months ago but abandoned as unneccessary given my typically short emails. I have to type URL links out in full, leaving potential for error. And gauging what amounts to a page-full read is tricky, since Blackberry is different page size.

But besides these caveats, the process is working well. And a great way to close a work day.

Agile development: first run

2007-05-14T18:41:00.001-04:00

I have been wanting to try Agile development for years, in fact I recently discovered this as a "goal" in my first 90 day deliverable in my current position. Being guided by a vendor, we now have our first foray in formal Agile development methodology, and the results so far have been above expectations.

The major benefits we've seen over waterfall methodology are (1) detailed daily progress (i.e. no surprises) (2) speed, and (3) quality. Our first project was a test-drive throw away, our next project will be put into production in a few months.

Attributes of the Agile methodology we are using, that we like, are:
- Dedicated Project room for team
- Test-driven development
- Thin slicing of functionality
- Fast, iterative development
- Estimating, tracking and predicting tools
- Programmer-centric (not Project Management centric)
- "Kaizen" – process reflection and improvement – i.e. http://www.projectkaizen.com/gang-of-seven/

The one attribute we are using but not yet sold on is Buddy programming. We see the benefits, but don't know enough to be 100% onboard.

The programmer-centric result comes as a surprise, but frankly has significant potential benefits for us, including more productive programmers. Will blog more on this another time.

(UPDATE: I sat in on my first Kaizen Agile retrospective meeting, and... WOW! Different does not begin to describe, but fun does!)

Inspiration, Technology and the US Army

2007-05-10T18:50:00.001-04:00

I spent the day at the Tristate CIO Executive summit in NY. It was a great one-day conference, although the 7:30am start and jacket/tie dress code were not my style (I complied). It was an excellent networking event, I encountered fellow New York CTO club members who like myself were masquarading as CIOs. Event was put on by SIM (Society of Information Management), which I will now join.

The highlight of the day was a presentation titled "Inspiring culture, collaboration and change", by Colonel Curtis Carver of the US Army, West Point. Besides Curtis being completely inspirational himself, I was amazed to hear that every West Point cadet trains in technology, hands-on. They build circuit boards, write code, config networks, and build 3-tier applications. That's every cadet, every future leader in the Army! I guess they've decided technology is important. Imagine if your CEO, CFO and VP sales/marketing had all programmed while completing their degrees?

The Army is also a huge user of social networking technology, connecting every platoon leader around the world online, creating case studies, promoting discussions online, outside of the regular chain of command. There was a later session on social networking in corporations, by Tsvi Gal of Deutsch Bank (and fellow New York CTO club member) and IBM. This is a big topic that I am really getting excited about.

New York CTO club

2007-05-09T17:30:00.001-04:00

We started the New York CTO club (Igor Shindel and I) because we saw that many CTOs did not have a good network to get advice from. My contacts in Silicon Valley all seemed to have good networks, having worked with Joe at Apple, or Mary at Sun, and therefore having folks from which they could seek subject-matter advice. So, we wondered if we could create a network via a CTO club. The first few monthly meetings were lame, but then something clicked at a meeting called "Vendor Intelligence" where we discussed different vendors we used and how and why. We extended this meeting into "Vendor Intelligence II" at our next monthly meeting, everyone got very into it. My own breakthrough moment was getting information about a vendor from three CTOs who had recently signed contracts, right as I was myself in contract negotiations.

The club is coming up on it's 7th year anniversary. We've had some great speakers (including this morning's, Michael Miller, who was Editor-in-Chief of PC Magazine for nearly 15 years), but what really makes the club is the comraderie between the members. The New York CTO club works because it's a community of CTOs (or similar position) who help and argue with each other about technology and business. The advice is just spectacular, and cannot be beaten. It also helps that we have the same location and time for breakfast every month, we meet early so everyone can get to their jobs by 10am. We share a Yahoo Group for emails, although a number of conversations go off-line after inital connection. We are close to 70 members strong now.

I can safely say that I would not be half the CTO I am today without the experiences and advice I've gotten from the New York CTO club.

First Blog

2007-05-09T16:03:00.000-04:00

This is my inaugural first posting. I am clearly late to the game in the bloggersphere (spelling?), but what the heck, here I am. I am planning (hoping :-) to post blogs via my Blackberry during my daily home train commute. We'll see how it goes.