Infovark

Does your enterprise software have an opinion?

Or does it just provide you with a bunch of tools, and little insight into how to use them?

Jason Fried, at 37 Signals has a seminal post about Opinionated Software. He argues that the best applications “take sides” and provide direction to their users.

From an engineering perspective, the best way to build a flexible solution is to build an abstract one. “Hey look”, said the guy who built SharePoint. “Everything that people do on their intranet is just a list!”

“There are lists of contacts, and lists of documents, and lists of folders, and lists of tasks, and lists of goals… Let’s build a generic list engine, and they can all use that instead of their home-grown corporate intranet.”

But a  problem arises when the customer buys into the marketing hype — into the idea of having a central, flexible collaboration center — and then gleefully tears open the cereal box and discovers… an abstraction.

“What’s that?”

“It’s a list engine. You can use it to share lists of all kinds of things, with all kinds of people.”

“Oh. Well, I wanted something that was going to help manage my projects.”

“Oh, it can — your projects are all just made out of lists.”

“They are?”

“Sure! Here, we’ll hire a consultant to explain it all to you…”

If you are trying to delight your customers, you need to step out of the abstraction, and into actual problems. Apple make opinionated software. Steve Jobs doesn’t think you should be able to cut and paste on your iPhone. That’s an example of the design forcing users to behave a particular way.

Part of SharePoint’s success in current iterations has come from partners, and from Microsoft providing users with built in “templates” that allow the user to skip the abstractions, and get straight to work managing projects, or processing insurance claims, or whatever it is they they do.

Abstractions are very, very useful to engineers, but by themselves are not very useful to the people who need to apply them in the real world.

If your enterprise solution is forcing you to learn weird abstractions, chances are the developers don’t really know what you want to do with it.

Paul Graham posted a Fundraising Survival Guide for start ups to his website. It’s a subject that’s been on my mind a lot lately.

When we started Infovark, we had roughly enough money to get through the first year. We did a fairly good job of budgeting, all things considered. We’ll be able to stretch our initial round further than planned, basically because we hired a few specialists under contract rather than another full time employee. We were also pleasantly surprised at the number of high quality software development tools you can get for free or at reasonable cost. (Microsoft’s Empower for ISVs was a particular boost.)

But when you’re a startup, the clock is always ticking. I can hear it now: “Time is money is time is money….” This is the mantra of the founder. It’s what gives us sleepless nights. It leads to fear and indecision. The search for additional funding can obscure the real goal of starting the company: building something useful — and having fun while doing it.

Infovark has by far been the best work experience of my life. Not merely because the Burrow is conveniently located in my basement — though it’s nice not to fight traffic — but because I’ve finally gotten a chance to create a product from scratch. I’ve never had the chance to do that before, and I’ve been learning a lot in the process. (That’s entrepreneur shorthand for making more mistakes faster than ever before.)

I’m really excited about this stage of the project. We’ve gotten an initial round of feedback from our alpha testers, and we’re mapping out the plan to get us to beta. But I can also hear the clock ticking…

That means at some stage — probably sooner than we’d like — we’ll have to leave the Burrow in search of funding. It’s a scary prospect for introverted software engineers. We’ll have to explain what we’re building, why we’re building it, and why you ought to invest in it. That means we’ll have to define why people will want to buy it and how much it will cost for them to get a copy. These are yet more things to add to our long, growing list of things that aren’t writing code. Except that getting funding is far from trivial, as Paul Graham points out. It’s a matter of survival.

I was just looking at a chart from Dr. Todd Stephens- an Enterprise 2.0 Blueprint:

For some reason, staring at this pretty colored chart made me quite cross. Not because the information in it was wrong or misleading. It was because this chart takes a scientific management-style approach to Enterprise 2.0. It prescribes the areas in the enterprise that you should consider when you try to pitch your Enterprise 2.0 business case. It aspires to be a guideline for building a “best practice process manual” to follow when your pitch succeeds.

An ant analogy

Imagine you took an anthill, removed every ant, set them carefully aside, and then completely demolished the anthill. Then you brought all the ants back and let them rebuild their anthill again. Would you have EXACTLY the same anthill as you did before?

I haven’t done that exact experiment, so I don’t know for sure, but when I shook my plastic ant farm as a kid, tunnels collapsed and ants scurried about. I’d imagine that the big feature on the Ant Nightly News was about the giant earthquake. Then I’d watch them start digging. After a few days, a new system of tunnels would appear. Life in the colony moved on. (Until the next big quake, of course.)

Studying the way that ants construct their colonies is fascinating. There was lots of room for me, as a 5-year old staring into a plastic ant farm, to speculate exactly what those chambers were for, and why the tunnels ran the way that they did. I couldn’t spot an ant architect with a tiny blueprint, yet somehow they knew what to do. It’s instinct, I guess.

Social animals

We humans have instincts, too. We’re naturally good at things like communicating and forming groups. We’re so good at it, we often don’t notice it happening.

When humans collaborate, we don’t build anthills. We build companies, and non-profit groups, and clubs and teams and associations and governments. These artifacts are what we refer to as “Enterprises”. Much like a colony of ants, enterprises are motivated by a handful of basic goals: resource gathering, manufacturing, growth, survival, etc. Those goals, along with the aggregated interactions of thousands of ants, result in interesting arrangements of tunnels. Shaking things up a bit will produce a different pattern of excavations even though neither the ants nor the goals have changed.

Corporate structure and processes often emerge in the same way as those tunnels. They can seem convoluted, inefficient, and sometimes just plain weird at times. It’s the legacy of thousands of small tactical decisions taken by workers each day. Enterprises are organic, just like anthills.

Nobody reads flowcharts

While looking at the existing structures of an enterprise is fascinating, I’m not sure it helps you plan the next tunnel. I believe that Enterprise 2.0 can improve a company’s tactical operations by better informing knowledge workers. Better informed employees can make better decisions — hopefully ones that lead to the emergence of a more productive enterprise. But I also know that I’d have a difficult time connecting an enterprise instant messaging client roll-out to the company’s bottom line in the same way that I’d have a tough time connecting two ants waving their antennae at each other to the construction of an anthill.

And if it’s tough to follow that chain of events, imagine how difficult it is to reverse engineer an anthill. When I see a colorful, complicated chart like the one above, I picture an ant with a clipboard and stopwatch, shouting, “Hey guys, wait a sec. Let’s plan these tunnels this time.”

A tunnels-first approach in the social world only leads to frustration. You’ve got to get the myriad interactions between the ants right first. Then the tunnels will work themselves out.

As Nate says in between mouthfuls of hummus,

One of the biggest battles I see beginning to rage is the push to have E2 implementations matter to “Corporate”. To me that doesn’t make any sense. Sure, they need to understand the benefits, but they should also understand that their benefits are byproducts of user benefits. These things work because of users. Not a mandate from Corporate. So focus on defining their value, and their value alone.

The most discouraging thing about running a startup is how long it takes to start up. Maybe that’s why I found The Myths of Innovation by Scott Berkun such a great read. He systematically demolishes common misconceptions about how ideas get to market. Just skimming some of the chapter headings made me feel better:

The Myths of Innovation

• The Myth of Epiphany
• The Lone Inventor
• There is a Method for Innovation
• People Love New Ideas

We’ve absorbed these myths into our culture because they make entertaining and memorable stories, but innovation rarely works that way. Edison had a team of reasearchers working for him and trial-and-error was his primary means of refining ideas. The advertising industry owes much of its existence to the difficulty of getting people to try new products and services. Sometimes it takes years for a new development to reach consumers, as was the case with 3M’s laughably weak glue formula eventually becoming the blockbuster Post-It note.

It’s good to be reminded of these counterexamples. The idea is often the easy part. It’s the execution that’s hard.