mini-cases: support your core

The new content-management system was done, and we breathed a sigh of relief.

We needed it to support our ambitions of providing even more specific content to our users, who came to our site for our well-informed professional recommendations in our area of expertise (about which I will remain ambiguous, for purposes of anonymity). The old CMS had been constructed in-house, and the new upgrade added a great deal of functionality.

There was only one problem: the writers and editors didn’t like it.

I had arrived at this company only a few months before, and was surprised to discover that, despite their core business as essentially an online magazine, they had decided to build their own custom CMS.

That didn’t make a ton of sense to me, given that even at the time, there were plenty of web-based publishing systems, from expensive enterprise-level solutions to open-source projects.

“The ones we looked at didn’t meet our needs,” I was told. “They weren’t flexible enough. And plus, we should be able to make money selling our CMS to other people.”

So the decision was made: take the existing CMS, update it with new features and capabilities, while retaining the same level of nearly-infinite flexibility.

But it nagged at me that the editors didn’t like it. They were the ones who had to use it, day in and day out. The way I saw it, even if the guy who built your house used some sort of highly-advanced construction techniques, it didn’t much matter if you couldn’t reach the cabinets and were always banging your shins on the stairs.

And constructing this upgrade presented its own problems. For the original developers—smart folks, I might add—I think it was just a question of how fast they could type. But for those of us trying to learn the system, it was like deciphering stereo instructions written in Egyptian. For all its flexibility, the code was incredibly obtuse; for me, raised on a philosophy of “just make it better and get it to the customer,” I was mystified by this insistence on absolute perfection at the code level at the expense of clarity.

And, mystified by the fact that the main developers didn’t seem to think it was necessary to do any User-Acceptance Testing with the writers. Or, to my recollection, even to ask their opinions.

The end result seemed like a dinner chair crafted out of the finest diamond: brilliant, internally perfect, and yet, utterly uncomfortable when put to use.

Did we meet our goal? Yes. We were able to roll out the desired new features. We didn’t hit our deadlines, mostly due to the struggles of developers like me, who either weren’t smart enough, experienced enough, or just familiar enough to comprehend the core code.
But the users of the site had their new information. And the editors had the tools they needed to provide it.

That doesn’t mean I consider the project to be a success.

The first lesson I took away from the experience goes back to the fact that there were two sets of users when it came to this new CMS: the readers of the site, of course. But also the writers.

And the writers, I felt, were utterly neglected.

I remember being in the training meetings with the staff, shortly after the new system was launched, watching them struggle to interact with the new system—this was, after all, the first time any of them had any input at all into the technology.

This would have made sense, had we decided to utilize some outside vendor. But this was a custom-tailored suit; why on earth hadn’t we even asked the people wearing it so much as their color preference, much less their precise measurements?

We had built a solution for one set of customers—the readers—and had utterly neglected the other. And the responses to their confusion from my fellow developers were shockingly dismissive, implying that they weren’t “thinking about things the right way,” that “they didn’t get it,” that “this is the way you need to work and that’s the end of it.” Utterly unsympathetic.

So the first lesson I took away was this: you have to consider all the users of your product when you’re designing a new system. Yes, people do tend towards the lazy, and yes, any change requires modification of long-established habits, but you can’t just shove something new in people’s faces and say, “Deal with it.” Especially if you custom-built the system in the first place!

User-Interface and User-Acceptance Testing aren’t just boxes you check the day before you launch. You need to involve real users in your process, or you’re going to have a lot of unhappy users in the end. And while internal users may not have much of a choice, shouldn’t you at least try to keep them happy? They’re your teammates! Why would you throw them under the bus?

The second lesson learned is that frameworks are fun. APIs are fun. Systems, languages, and architectures are fun.

Have you ever asked a developer to perform a task and heard the reply, “I just need to build out a framework, an Application Programming Interface, a tool, a language, a system, and then it’ll be trivial to do that thing that you wanted.”

This is a dirty rotten lie.

The truth is, performing tasks is like painting the barn when you’d rather be painting the Sistine Chapel. It’s often menial, boring and dull.

But it pays the bills. That’s the problem: programmers want to do work that is exciting, innovative, and creative. And if you work for Google, Microsoft, Apple, or any other company who has taken up the mantle of envelope-expansion like a modern-day Xerox PARC (look it up), that’s just great. Somewhere, there’s a sales and marketing guy dedicated to selling your brilliance.

In most companies, though, their needs e.g. Innovation involve getting the server to not crash and figuring out why the CEO can’t seem to get his Internets to work right.

Fun? No. But when the server is up, the company makes money. Which pays paychecks. And keeping the CEO happy is also important, in terms of not getting fired, and based on (hopefully) his/her leadership for the organization.

All this integrates quite nicely into the third lesson of this case: focus on your core business.

Was our core business building content-management systems?

No.

So why did we build our own?

I frankly think that the answer of “we couldn’t find one that would meet our needs” was an excuse presentedby programmers who didn’t want to solve boring (but important) business problems; programmers who instead wanted to show off their chops. I’ve frequently been guilty of it myself.

Is a commercial solution “good enough?” Can you make minor modifications to your business to accommodate the shortcomings of the tool everybody else is using?

If the answer is “no,” you need to really, seriously re-evaluate. Are you that unique?

And does it matter? Shouldn’t the content of your opinions matter? If you’re making a movie but can’t afford the latest 3D technology, can you step back for a second and ask yourself, “can I tell an effective story without this technology?”

Listen: if you truly depend on innovation, innovate. Good luck. It’s hard enough to start a new business working in an established field. Trying to do it while simultaneously building a market is almost impossible. But it has been done, and continues to happen.

First, though, think about your core business. What brings in revenue for your company? That’s nice that you might someday open a shop to sell the cupcakes you bring to the company picnic. And everybody agrees that the pictures you’ve taken of your cat are adorable.

But are you going to quit your job to sell them?

Then why would your employer embrace a line of business outside of their declared practice?

If you’re still struggling with this one, think of it this way: would you buy the best brownies on earth from Jiffy Lube? Would you trust Microsoft to walk your dog? Would you buy a suit from Budweiser?
Do what you do. Think long and hard before you expend significant resources on other stuff.