Features are not chunks of code

photo credit: nandadevieast (Flickr)

Before the industrial age, “features” were noteworthy aspects of a face or a geography: a patch of color, abundant wrinkles, a scar… The human brain is stunningly good at identifying and comparing such features–perhaps because that ability has been central to our nurture as children, our bonding into family units, and our survival as a species.

When we want to say what a face looks like, we describe its features. They are an entrée into experience with it.

At the dawn of the computer age, the advertising and publishing industries were already talking about how products–or aspects of them–could be “featured” in media. Highlighted characteristics were called “features”, and this metaphor transferred seamlessly into digital language. Software product managers now traffic in “features” and “feature sets.”

We use the term so comfortably that we sometimes forget what it has to teach us.

Continue reading

All I Really Need To Know I Didn’t Learn In Compugarten

I’m glad newly minted software engineers are exposed to data structures, compilers, concurrency, graph theory, assembly language, and the other goodies that constitute a computer science curriculum. All that stuff is important.

But it’s not enough.

Not all classroom material for CS folks should be technical. Photo credit: uniinnsbruck (Flickr).

Since I’m half way to curmudgeon-hood, I frequently find myself lamenting educational blindspots in the young. I’ve even toyed with the idea of teaching at the nearest university, some day when I Have More Time™. If academia would take me, my lesson plans might cover some of the following topics:

Lynn Bendixsen: Listen.

(A post in my “Role Models” series.)

When I worked at Perfect Search, we had a standing joke that after the meeting agenda was done and we had given the word to adjourn, it was time to turn to Lynn and get his feedback. This joke was funny because on many occasions we’d seen Lynn ask penetrating questions after the rest of us rushed headlong through an issue and assumed all the thinking was done.

Although Lynn tolerates this joke with good grace, I think the joke isn’t really fair to him, because there’s nothing funny about thoughtful listening. The world could do with more people who’ve mastered Lynn’s skill.

Listen to understand, not to respond. Photo credit: Prisoner 5413 (Flickr)

I recently blogged about the importance of humility. It is not an accident that humility Continue reading

Humility

I was applying for a very senior architect role. I’d already been through several rounds of interviews with a whole committee of thought leaders in the department. I’d taken a technical proficiency test, and (I hope) given a good impression about how I’d be able to contribute.

The CEO cleared a block on her schedule and sat down with me. She poked a bit at my business experience, my ideas of process, and my aspirations. Then she said, “Tell me your thoughts on humility.”

I think it’s the best job interview question anyone has ever asked me.

A great perspective on humility. Photo credit: Chiot’s Run (Flickr).

Real humility

A person trying to fake humility says, “I’m not very good” — but doesn’t mean it.

A person trying to be humble, but misunderstanding its nature, says, “I’m not as good as X” — and tells himself it’s probably true.

A truly humble person Continue reading

6.0 Syndrome

Software products get inertia. A team works on one version of the product–pours their heart and souls into it, if the team is dedicated and passionate–and eventually ships.

So what comes next?

This is a silly question, right? If you just built version 5.0, then 6.0 is next. Or maybe 5.1. Unless marketing decides to call it Contraption 2013 instead.

A highly-evolved contraption. Photo credit: Argonne National Laboratory (Flickr).

I’d like to suggest that it is healthy to wonder if you should build a new incarnation of your current product at all. Sometimes, if you’re smart, you’ll realize that the answer is no.

It is not crazy that the default posture of dev teams is to release a new-and-improved version as a follow-on–staffing teams, organizing marketing, communicating effectively to the market, getting sales traction, and aligning your support and professional services teams on a common axis are all expensive and time-consuming.

However, the right solution to the world’s problem tomorrow might not be a slight variation on something you’ve already built. Companies that forget this are going to keep improving their tape decks even as CD players begin to ship. (If that reference seems archaic to you, you’ve proved my point yet again. CD players became a lot less compelling once personal mp3 players were a possibility…)

Clayton Christensen is famous for writing about this in The Innovator’s Dilemma, but I like his Blockbuster/Netflix example in How Will You Measure Your Life even better.

I’ve seen good examples of thinking outside the box during my career. The decision at PowerQuest to invest in disk-based backup instead of building another version of PartitionMagic comes to mind. But I’ve also seen the opposite–blind commitment to version 5.0 and 6.0 to such a degree that teams could not innovate.

Seth Godin writes insightfully about this in Poke the Box:

[Most organizations] are based on this assembly line model of scalability. The system is the system. Don’t mess with it. … Now, think about Apple, Google, director James Cameron’s team, Ideo, Pixar, and Electronic Arts. These are project-centric organizations. … No projects, no organization. Coasting isn’t an option because projects don’t last forever. The people stick around, the posture persists, but the projects need to be refreshed.

It feels to me like one way to encourage innovation in a software-creating org is to not assume that there will be a next version. There may be–but once this version ships, we spend at least a little time with first principles, re-validating assumptions about what can best delight customers.

Action Item

Analyze where your current product fits on Clayton Christensen’s model of innovation vs. mature product. Does this suggest anything to you about a need for radical (as opposed to incremental) innovation?