Every startup needs this toy from ThinkGeek.

As you can see, our self-destruct button is fully disarmed.

However, the nuclear option is always available.

It’s just one of those little things that keeps us awake at night.

Continue Reading

Infovark’s been in operation for six months now. In that time, we’ve written more than 100,000 lines of code and posted more than 50 blog articles. But  — we still don’t have a product yet.

By the original timeline we drafted in October 2007, we should be in Beta by now. So, it was time to take a good hard look at our schedule. We were harsh with our estimates.  And when we looked at our projected workload, we were suitably scared. (I’m sure that if you aren’t at least mildly terrified by your software schedule, you really haven’t done it properly).

So, after taking stock of what we’ve done and what we have left to do, we’ll hit Alpha some time this summer. (We hope!)

What’s taking us so long? Well, for one thing, all software projects run late. This is expected behavior for software development. Though we’d like to think we had our whole solution mapped out from the start, we’ve discovered a lot of things we needed to have, eliminated a lot of frills, experimented with different technical approaches, and, yes, wasted time.

That’s the nature of creative work. Software development is not really an engineering discipline, though we’d like it to be. It’s more like writing the great American novel. Some mornings you can write a whole chapter before your first cup of coffee. Other mornings you struggle to find the right word to begin the first sentence. Still other mornings you spend crossing out all the bad ideas from last night.

All in all, we’re pleased with our progress so far, but we’re going to need a longer runway than we thought before we can take off. That’s OK; for now, we’ve got the cash and our expenses are low. Our biggest worry is that we might miss the window of opportunity for enterprise social software. Or that someone else might beat us to the finish line. It’s a healthy concern. It keeps us motivated.

So we’ll keep scrambling to get our ideas into code form. In the meantime, we’ll keep you posted on our progress. And you can help us out by telling us what you’d like to see in enterprise social software.

Continue Reading

We’ve decided to create a separate blog specifically for techies. We call it infovark Underground. It describes all the cool technology stuff we’re doing under the covers. Its target is other software architects and developers.

Our primary blog will still be this one at http://www.infovark.com. It will deal with issues of enterprise 2.0, social networking, and running a small ISV. Its target audience remains knowledge workers (our customers, hopefully) and industry watchers (our advocates, hopefully).

We debated about addressing everything in a single feed, but decided that we were really dealing with two different audiences: those that care about business problems and those that care about code problems. And even though we at infovark are deeply interested in the intersection of those two worlds, we know that not all visitors to our site will feel the same way.

We’ll try to keep cross-posting to a minimum, but we’ll occasionally link from one to the other if a topic applies to both communities. After all, Enterprise 2.0 is about social technology, isn’t it? We’d like to help build bridges between the MBA suits and the IT geeks.

Continue Reading

Jeremy Thomas, over on Social Glass, asks if “Enterprise 2.0 is only relevant to doers“:

“…Management spends most of its time in meetings reporting progress and being appraised of new initiatives. Does Management really have time to make sense of all of the blog posts, wiki pages and social bookmarks in their Enterprise 2.0 Solution? I’m not sure they do…”

It’s an interesting question. In my last job, my two bosses would sit me down once a week to give them a brain dump of the ten or so different projects I was working on. They’d furiously take notes about what was under control and what was on fire so that they could report up the management chain, respond to clients, and focus my efforts.

There were two problems with this weekly ritual. One was that I was often so engrossed in in whatever I was working on on Friday that I’d forget the stuff I’d done on Monday. For fast-moving projects, they could schedule additional mid-week meetings, but that raised the second problem: The time I spent discussing status was time that couldn’t be spent on getting work done.

It’s a tricky balancing act. Much of the art of management is calibrating the frequency of status reports. Monitor too closely, and nothing gets done. Monitor too infrequently, and you miss out on important information.

A lot of this E20 stuff is about transparency — improving employee awareness within the organization. Better visibility helps managers too — perhaps more than the average employee — but they’ll need a different set of tools to search and filter social content than “doers” will. The knowledge worker needs to find content so that they can do their work. A manager of knowledge workers needs to find out about the status of that work so they can measure progress and productivity.

Managing people becomes a lot less complicated when you don’t have to constantly pester your staff to see what they are up to. Since Enterprise 2.0 encourages transparency and visibility, there’s more ways for management to find out what’s going on. Workers can spend more time working and less time on TPS reports, which increases productivity. Managers gain a more accurate picture of project status, which increases accountability and leads to better decisions.

The challenge is that managers have more data to monitor and measure, and frankly, the tools just aren’t there yet. (Though we’re working on it.) In the long run, I think management might have more to gain than the people actually doing the work.

Continue Reading

Here’s an elegant restatement of the battleship gray syndrome in pen and ink, provided by It’s Just a Bunch of Stuff That Happens.

Found via ReadWriteWeb.

Continue Reading