Don't Master Your Tools

Ever notice how using the full power of Microsoft Office makes the team less productive. Perhaps I exaggerate, but think about these examples:

• I use style sheets in Word to get a consistent appearance from my documents, and to allow me to easily adapt documents to my clients' preferred formats. However, when someone else uses my documents they don't use the style sheet. The formatting becomes inconsistent in mysterious ways, and you very rapidly get to a state where you can't rely on the format being right unless you review the whole document. But using a word processor is supposed to be about easy changes, isn't it?
• I can make a nice, easy to maintain financial model in Excel, but someone who doesn't know how I do things will probably break it within the first dozen edits or so. Often a broken spreadsheet isn't obviously broken, which can lead to disastrous consequences. I worked on a project once where the program director had to sneak into the office of a VP at Canada Post and retrieve a document because the financial numbers were wrong by a factor of two thanks to a spreadsheet error.

I'm talking about working on teams with IT professionals. If we don't know and use our tools productively and consistently, who will? What I mean is that I don't think it's a training or education issue. If there was a clear benefit to everyone to learn how to use Word or Excel at the power level in the team context (not individually for things that we only use ourselves), we'd already be doing it.

For word processing, I think the Web has shown something very interesting: You can communicate a lot with a very small set of styles. Look at the tags that you can usually use within a blog post and you'll see that there aren't many. I wonder if there's a market for a super-small word processor that has 10 buttons to do all formatting? (Sticking with the HTML-based idea, I'd say 10 buttons for formatting, but you're also allowed to have a front-end that gives the user access to different classes in a cascading style sheet.)

I think the financial modelling problem is different. At one level, it might involve some simple changes like making it harder to accidentally change a formula back to a fixed value. At another level, it's about letting people express what they want to do, not how to do it. That's starting to sound like the old idea that someday we'd just write requirements and the CASE tool would generate the code automatically, so I'd better shut up. :-)