Your Company's Leaking Knowledge

This article appeared as my column for Connect Magazine in April 2005.

Your company leaks knowledge. Employees leave and even die. Little by little, your ability to continue doing what you're doing walks out the door. Even worse, in many case, only a few people really understand the product and they, as the saying goes, "better not get hit by a bus." If you ran a manufacturing plant, you'd be foolish to let the infrastructure languish, but too few knowledge companies pay much attention to managing their intellectual infrastructure.

An important part of that infrastructure is nomenclature, the language that organizations use to discuss their technology and products. Too often, techies are prone to see this as "just branding." And after all, what could branding have to do with building software?

Nomenclature, however, is much more than just branding. Nomenclature can define a market and help the company see how it fits into that market. Craig Burton, the VP of Marketing for Novell in the 1980's, used language to redefine the network from a bundle or wires to a set of services. In the process, he created a vision for what Novell would become and launched a whole industry. The ideas weren't necessarily all his, but he defined the language and that defined the market.

I've come to see the role of CTO in terms of how they help define the product language and in doing so, not only talk to the market, but also create a vision for the technical team. Looking back on my experience as CTO of iMall.com, I think we did a pretty good job of building nomenclature, but it was more of an accident than an explicit choice. Since then, I've had other experiences that have grounded this concept for me and helped me understand it better.

For example, I've been working with Utah's Aradyme Development Corp. as they define the language they use to talk about their software--both inside and outside the company. Not surprisingly, this has helped management and the sales team talk to customers. What's more, the technical team now has a better vision of what they build, support, and use.

We started off with a lot of meetings where I asked lots of questions and drew pictures on the whiteboard anytime they'd let me near a marker. The goal of these sessions was to build some common understanding among the participants about the product and its place in the market.

Next, we started creating strawman models that included names, definitions, and architectural drawings of the major components of the product and how they relate to each other. These strawmen were debated and refined--it's a messy process. I'm always amazed how much passion a set of colored boxes and lines can generate, but that's indicative of how important this process is. The arguments reflect places where people have different mental models, so don't paper over the disagreements. Keep at them until everyone comes to consensus.

Somewhere in all the talking, you'll start to create a language that describes your product. Don't leave the business side of the organization out of these discussions. Otherwise, the language won't be universal and you'll continue to have the technical folks and product people talking past each other. Furthermore, you won't have the insight that they can give you about the only people that really matter: the customers.

After we reached consensus on the nomenclature for the product, we wrote whitepapers. Whitepapers are the lingua franca of this process, the place where the ideas can be distilled and tested one final time. They help educate customers and employees alike, especially new hires, in how the company talks about its products and the mental model it uses to think about them.

If this sounds like marketing to you, then give yourself a prize for being one of the few that recognizes marketing for being more than PR and creating slick brochures. Who's job is it? At iMall, the product marketing team reported to me and I think that worked out beautifully. Product definition is the prime job of the CTO. CTOs who just manage the developers should be called what they are: the VP of Engineering. Real CTOs manage the product and ought to be as good at product marketing as they are at engineering.

You may not redefine an industry the way Novell did, but the value of building nomenclature isn't in redefining markets, the value is in giving your company a common vision about the product you build and its place in the market. World domination comes later.

Phil Windley teaches Computer Science at Brigham Young University. Windley writes a blog on enterprise computing at http://www.windley.com. Contact him at phil@windley.com

Last Modified: Tuesday, 08-Feb-2005 20:17:36 UTC