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.