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.