Technology around the globe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

</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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Is the Blackberry anti-social?

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

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

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

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

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

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

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

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

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

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.