June 16, 2008 | Comments: (0)
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.
Posted by Jon Williams on June 16, 2008 05:39 AM
June 12, 2008 | Comments: (0)
Agile and the social developer
I was talking the other day to a technologist who had made the switch early in his career from software development to infrastructure. I asked him why, his answer:- "I didn't want to spend days not interacting with people".
When I was a software developer, it was a lonesome affair. There was no open source community, just manuals and API docs. I got the occasional check-in from my boss and questions to a sysadmin, but mainly was left alone (and liked it). My response to passers-by as to my well-being was often a grunt, as I maniacally focused on the code on my (green) screen in front of me. But that was in the days before agile development.
Agile development practices require a developer to be social. There's a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction. Even open source development is by its nature social. There's no room for a loner.
One of the reasons I stopped coding and became a manager is because I enjoy social interaction (I've been accused of being a "social animal" :-). I do get a buzz out of an interactive tech meeting with developers, admins or CTO peers. For me, this begs the a/b question:- (a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?
But clearly, an agile developer is a social developer. That's a good thing.
Posted by Jon Williams on June 12, 2008 08:42 AM
June 09, 2008 | Comments: (0)
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.
Posted by Jon Williams on June 9, 2008 12:00 PM
May 08, 2008 | Comments: (0)
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!.
Posted by Jon Williams on May 8, 2008 05:42 AM
April 17, 2008 | Comments: (0)
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.
Posted by Jon Williams on April 17, 2008 07:00 AM
April 15, 2008 | Comments: (0)
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...
Posted by Jon Williams on April 15, 2008 09:14 AM
April 03, 2008 | Comments: (0)
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?
http://weblog.infoworld.com/openresource/archives/2008/03/kaplan_guiding.html?source=rsshttp://www.cnet.com/8301-13505_1-9903582-16.html?tag=head
Posted by Jon Williams on April 3, 2008 08:11 AM
March 27, 2008 | Comments: (0)
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 :-)
Posted by Jon Williams on March 27, 2008 07:36 AM
March 13, 2008 | Comments: (0)
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.
Posted by Jon Williams on March 13, 2008 09:18 AM
March 03, 2008 | Comments: (0)
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).
Posted by Jon Williams on March 3, 2008 08:33 AM
February 19, 2008 | Comments: (0)
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.
Posted by Jon Williams on February 19, 2008 10:14 AM
February 14, 2008 | Comments: (0)
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?
Posted by Jon Williams on February 14, 2008 12:44 PM
January 28, 2008 | Comments: (0)
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.
Posted by Jon Williams on January 28, 2008 08:50 AM
December 10, 2007 | Comments: (0)
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.
Posted by Jon Williams on December 10, 2007 05:46 PM
November 26, 2007 | Comments: (0)
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.
Posted by Jon Williams on November 26, 2007 06:46 AM
November 13, 2007 | Comments: (0)
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.
Posted by Jon Williams on November 13, 2007 06:41 AM
November 08, 2007 | Comments: (0)
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?
Posted by Jon Williams on November 8, 2007 01:24 PM
November 05, 2007 | Comments: (0)
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.
Posted by Jon Williams on November 5, 2007 05:38 PM
October 17, 2007 | Comments: (0)
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?
Posted by Jon Williams on October 17, 2007 05:42 PM
September 27, 2007 | Comments: (0)
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.
Posted by Jon Williams on September 27, 2007 10:31 AM
September 20, 2007 | Comments: (0)
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.
Posted by Jon Williams on September 20, 2007 07:29 AM
September 14, 2007 | Comments: (0)
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?
Posted by Jon Williams on September 14, 2007 05:53 PM
September 12, 2007 | Comments: (0)
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.
Posted by Jon Williams on September 12, 2007 11:34 AM
August 16, 2007 | Comments: (0)
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.
Posted by Jon Williams on August 16, 2007 06:43 PM
August 13, 2007 | Comments: (0)
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.
Posted by Jon Williams on August 13, 2007 10:13 AM
August 09, 2007 | Comments: (0)
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.
Posted by Jon Williams on August 9, 2007 07:46 PM
August 07, 2007 | Comments: (0)
(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.
Posted by Jon Williams on August 7, 2007 12:07 PM
July 23, 2007 | Comments: (0)
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.
Posted by Jon Williams on July 23, 2007 05:20 PM
July 23, 2007 | Comments: (0)
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.
Posted by Jon Williams on July 23, 2007 06:10 AM
July 17, 2007 | Comments: (0)
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.
Posted by Jon Williams on July 17, 2007 01:28 AM
July 11, 2007 | Comments: (0)
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.
Posted by Jon Williams on July 11, 2007 06:53 AM
July 09, 2007 | Comments: (0)
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.
Posted by Jon Williams on July 9, 2007 05:22 PM
July 04, 2007 | Comments: (0)
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!
Posted by Jon Williams on July 4, 2007 05:26 PM
June 29, 2007 | Comments: (0)
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?
Posted by Jon Williams on June 29, 2007 12:51 PM
June 27, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 27, 2007 05:39 PM
June 26, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 26, 2007 09:11 PM
June 26, 2007 | Comments: (0)
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 fall short, you'll need to make sure your teams and contacts have a working cone of silence with you.
Posted by Jon Williams on June 26, 2007 09:09 PM
June 25, 2007 | Comments: (0)
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, including names):-
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 cumulative 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.
Posted by Jon Williams on June 25, 2007 05:45 AM
June 22, 2007 | Comments: (0)
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, 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?
Posted by Jon Williams on June 22, 2007 05:24 PM
June 22, 2007 | Comments: (0)
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!
Posted by Jon Williams on June 22, 2007 06:11 AM
June 20, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 20, 2007 11:16 AM
June 20, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 20, 2007 11:14 AM
June 16, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 16, 2007 06:56 AM
June 16, 2007 | Comments: (0)
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)
Posted by Jon Williams on June 16, 2007 06:55 AM
June 14, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 14, 2007 04:31 PM
June 13, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 13, 2007 05:30 PM
June 13, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 13, 2007 05:29 PM
June 12, 2007 | Comments: (0)
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.
Posted by Jon Williams on June 12, 2007 07:22 PM
June 11, 2007 | Comments: (0)
I've gotten this question alot, "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 progamming language is hard), but it does require a different approach, a different point of view.
This blog is targetted to technology managers or "would be" managers. I manage every day, and I hope my little insights help you achieve your management goals.
(See my first 20 postings at http://newyorkcto.blogspot.com)
Posted by Jon Williams on June 11, 2007 05:34 PM
TOP STORIES
ADDITIONAL RESOURCES
- Do you have the power to resolve technical issues with one call?
- Take control of your content- leverage Microsoft SharePoint
- Keeping the E-Mail Flowing
- How Does Your IT Help Desk Measure Up?
- Best Practices for the Service Desk
- Discover How to Provide Anytime, Anywhere IT Support
