Hair-Raising Words

My daughter just got back from touring a “haunted circus” with her friends. She reports that the clowns were terrifying. (For those who aren’t living in North America, the Halloween holiday is a time when the macabre and spooky are in vogue.)

Coulrophobia–the fear of clowns. Image credit: Graeme Maclean (Wikimedia Commons).

Well, I’m a programmer; I can get chills down my spine without paying an entrance fee. All I have to do is go to a meeting where certain words get tossed around casually. Blood drains from my face; my heart starts racing; visions of apocalypse dance before my eyes.

Okay, maybe I’m exaggerating a teeny bit–but I have found a few words that have a near-magical capacity to provoke stress, worry, and miscommunication in companies that make software. Here is my short list: Continue reading

Why Cannibalism May Be Smart Business

Get out your fork. I’ve got a story for you…

Dig in. Don’t hold back. Photo credit: AleBonvini (Flickr)

At the beginning of 2005, Symantec acquired Veritas. Together, Veritas’s BackupExec and NetBackup products accounted for something like 70-80% of the world’s enterprise backup market. As I recall, BackupExec had annual sales of around $600M, and NetBackup was similar.

I worked for the only technology group within Symantec that overlapped the backup space at the time. We were making a disk-based backup product named LiveState Recovery; its revenues were in the tens of millions of dollars and we were growing at >100% CAGR.

Integration gets hairy

Our growth stemmed from the fact that we were approaching backup in a radically different way. Instead of capturing changed files and streaming them through a centralized media server to a tape library, we took disk images based on snapshotting technology. We were faster (many times faster, often); we had a distributed architecture that scaled out much more easily; we never missed a bit; we captured application state perfectly; we could mount backups or convert them to virtual machines.

As the acquisition finalized, Symantec charged us and the BE folks Continue reading

Ken Ebert: Kill three birds.

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

Killing birds is just a metaphor; who’d want to hurt something this cute? Photo credit: Valerian Gaudeau (Flickr).

Most people optimize for a single outcome.

Ken Ebert is made of smarter stuff.

When I began my career, I was like many engineers–keenly aware of issues like code quality and performance, but not so clued in to customer experience or business priorities. I’d go to team meetings, get new assignments, and head back to my cube to code away. If I was unsure how to accomplish my goals, I’d ask a senior engineer, and do my best to reflect the values they cared about. After all, they were the experts.

It gradually dawned on me that some of my engineer mentors (not many; geeks are better-rounded than popular stereotypes make them out to be…) suffered from a kind of myopia. They could build complicated and highly functional things, but they had little interest in how their constructions mapped into sales, revenue, and company success. I went through a revolution in my perspective, got religion about user experience, and spent a lot of time learning from product management.

In 2003, Symantec acquired several companies in rapid succession, and threw five sites together into a new business unit with marching orders to build a suite and conquer the world. I was tasked with architecture across the picture, and my perspective expanded again. Now it wasn’t just a single product’s success I was worrying about–I had to make or shepherd design decisions that enhanced the profitability of multiple independent products as well as the amalgam of all of them. Was it more important to make codebase X localizable, or to invest in a better install for codebase Y? If team A moved to a newer version of tomcat, would it break the integration story for our suite or impose undue burdens on team B? Resources were constrained (they always are!), time was short…

I began to sense that the way I made decisions needed to change, but it wasn’t until I worked intensely with Ken Ebert, years later, that I could put into words exactly how.

Making wise decisions about architecture, SOP on dev teams, product features, investment in R&D versus marketing–it’s like trying to solve an equation with multiple variables. Profit maximization requires that you consider more than one input at a time. This is partly what I had in mind when I blogged about the need for balance in good code, and when I blogged about optimization.

Many times I’ve heard Ken say something like this: “I think we should make feature N the centerpiece of our next release.” And my first response has been, “That’s doable, but kinda boring. Why not focus on M instead?”

When Ken nods sagely at my question, I know what’s coming.

N is glamorous, and low-risk, but it’s only useful to 3% of our customers. If we build M, we’ll address a sales inhibitor for half the funnel, plus we’ll be positioned to do features P and Q on our long-term roadmap, plus I’ll be able to get an analyst to write about it, plus …, plus …”

Ken doesn’t just kill two birds with one stone. He kills three, or five, or six.

I’m not sure how Ken manages to be so good at this, but here’s what I’ve done to try to approximate his success:

  • Evaluate in multiple time horizons.
  • Evaluate for the channel as well as direct sales.
  • Evaluate for support and professional services as well as dev.
  • Evaluate for marketing value.
  • Evaluate for opportunity cost.
  • Evaluate with an eye to domino effects.
  • Evaluate for morale and momentum.
  • Evaluate for technical debt.

Of course, nobody can do all of these, exhaustively, all the time. Don Kleinschnitz’s wisdom about putting a stake in the ground is an important counterbalance. But I find that I can think, at least briefly, about ramifications of a choice from multiple perspectives–and when I do, I often make better choices.

Thanks for the lesson, Ken.

Action Item

Look at the bulleted list of perspectives above; find one you’ve been neglecting. Pick a significant decision that’s on the horizon, and spend some time thinking seriously about that decision in the context of the neglected perspective. What did you learn?

Why Weakened Dev Teams Suffer From NIH Syndrome

(NIH = Not Invented Here)

So here’s the situation. Product Management says feature X must be built. Development scopes the feature and discovers that the “right” solution involves using code developed elsewhere. But unfortunately, the other team’s code uses different assumptions and will take some extra time to shoehorn into the new context. In other words, the right solution is too costly.

If a development team doesn’t have an architect who can advocate for the right solution based on first principles, then it uses the tried-and-true scope/schedule/resources lever (about its only negotiating tool) to push back.

The problem is that in this scenario, product management isn’t really forced to come to terms with the long term strategic consequences of doing things wrong. So the scope is adjusted, or the schedule is adjusted, or the resources are adjusted — but only enough to rescue the feature, not enough to do it right.

As a result, dev has to invent a half-baked alternative to the other team’s solution. Ad nauseum.

We look at the dev team and say that they have “Not Invented Here” Syndrome, because they never seem to use the solutions that other teams have built. In many cases, the real problem is that the Product Management and Dev don’t have an architect mediating and looking at the situation from the standpoint of maximizing the ROI of strategic technology investments.