Team Intelligence

In many knowledge-intensive service-oriented verticals, working as a team to handle the overwhelming work load from your clients is of critical importance.  As a typical example, partners in law firms are typically completely overwhelmed with requests from several dozen or more of their clients, and are looking for ways to reduce the turn-around time, so as to provide a superior client experience for their customers.   This goes way beyond getting back to your clients quickly, but also includes being “ahead of the ball”, and of course never dropping it.   Simply put, when you are dealing with high-touch, high-value clients, you are expected to provide a high level of service, and the high-bandwith connection between the team and the client is of critical importance.

At Kalexo, we researched different verticals with this characteristic, and discovered that one of the core issues is that the back-office team has a hard time scaling up.  Adding more people to a team does not translate into faster turn-arounds and better service when you have a hard-time balancing the work across the team.    The problem is quite pronounced in service organizations that are heavy users of email and meetings to coordinate activities.  Often the information you need is either in the head of somebody else or in the wrong inbox.    Getting the right information in the right hands becomes a full-time communication and coordination task.

A critical part of Kalexo’s solution to scale up teamwork is the concept of an easy-to-use shared database of activities coupled with innovative dashboards and analytic capability to keep the pulse on the team.    (You can’t provide superior service if you can’t measure it. )   We’ve developed new ways to ensure the team database is always up to date, and that it does not become a burden on the team.    The latter area is particularly interesting since we are working on new ways to plug your clients right into your team, which makes it a win-win for both the team and your clients.

As usual, more information in follow up postings.

Wikipedia has the following to say about RIAs:

Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e maintaining the state of the program, the data etc) back on the application server.

Recently there has been a surge of interest in offline operation or “occasionally disconnected” clients that allow you to continue working without an Internet connection.   This is of course a critical requirement for Enterprise 2.0 applications where connectivity is not always available.   Even though we are getting more connected than ever, we have to face it that a lot of work is done in somebody-else’s conference room and on the plane, and getting access is not that easy (or cheap).

The trick to make offline operation work is synchronization.  When you work offline, all changes are “remembered”, and when you connect again transmitted and integrated into the back-end database.  It is a pretty complicated system to engineer but generally works without the user noticing the complications.  

Most of the RIAs use centralized databases where the heavy lifting is being done.   We can however also imagine having no centralized database at all.  If the data is anyway on the client machine to allow for offline use, it begs the question what need the centralized database is for more than synchronization of the clients.  If synchronization is the purpose, then the centralized database can be replaced with a very simple log of changes  Such an organization has cost advantages for a service provider, the biggest being that you don’t need that large an investment in database server infra-structure — the heavy lifting is pushed to the clients.  So we are moving from “occasionally disconnected” to “occasionally connected”.

This is not a theoretical argument for using distributed databases in rich internet applications.   At Kalexo, our platform underpinnings is exactly such a distributed database that synchronizes in real-time over secured instant messaging networks.  We use a light server infrastructure that is completely fault tolerant and in fact most of the time redundant. 

We have not publically spoken about our technology, so this is the first time you will hear about it.   It took a lot of blood, sweat and tears to build the platform, and it had several repercussions not initially anticipated.  We ended up building a complete and fully-functional RIA stack, both client and server, to make the whole thing work.   The result is something which we believe is unique, which translates into software applications where you can do some very interesting and really cool things.

Of course, all this technology is naught without a really cool application on top of it.   More of that in follow up postings !

I found an interesting article at Computerworld with the following tag line:

Even the most sophisticated company is really a bunch of people making promises to one another.

One of the interesting statements it contains is that a promise is stronger if it is made in public.  The same dynamics apply for general teamwork (the article focuses on situations involving cross-corporate boundaries).   Unfortunately there is a lot of scope for not delivering on a promise due to how we use software tools like email.  Information / promises are often locked away in the wrong inbox, and there is no way to access it, and hence nobody really knows that a promise was made.   Of course, even if your inbox with possible promises was accessible to the right people, it is practically impossible to find them.   This is a dilemma the new product manager often faces when handed the inbox of his predecessor.

From TechRepublic:

1. Know why the organizer called the meeting
2. Know what you want from the meeting
3. List what you need to say
4. Take the meeting minutes
5. Keep to the rules of order
6. Reflectively listen in information meetings
7. Set things that derail aside
8. Ask for action items
9. End the meeting when it is done
10. Ask questions afterwards

Agendas are the most effective way to run a meeting, and also the recommended way of getting out of a meeting. If you have an agenda for a meeting, and it is published in advance, not only can you decide if you need to be in the meeting, but it also gives you the option to complete items before attending.

Research available from here indicates that although teamwork does have a positive correlation with your financial performance, it does not seem to make a difference whether the team is autonomous or not:

The results of this study confirm the popular belief in management circles that team production is a good bet for enhancing organizational performance. The median establishment in a large cross section enjoys a considerable increase in the probability of higher financial performance by using team production, and the benefits are considerably larger for establishments at higher quantiles. Furthermore, even at low quantiles of the team effect, statistical evidence of a detrimental effect of teams on financial performance is quite weak. This suggests that the upside from team production is much larger than the downside. Contrary to the commonly held belief in the management and academic communities that self-managed or autonomous teams are preferable to closely-managed teams, the evidence suggests that non-autonomous teams are no worse, regardless of the autonomy measure considered.

It seems like the things you assume about how a great startup is born might be misleading you.   I  am starting to suspect that the most valuable things I’ve learned at the previous companies I worked at was what not to do.

Wikipedia has the following to say about persuasion:

Persuasion is a form of influence. It is the process of guiding people toward the adoption of an idea, attitude, or action by rational and symbolic (though not only logical) means. It is a problem-solving strategy and relies on “appeals” rather than force.

The most effective way to persuade is via face-to-face communication. As a manager you quickly learn if you want to make sure something gets done, there is no substitute for staring that person in the eye when discussing the topic. This explains why meetings are so popular to get everyone “on the same page”.

So when I run into a company where an excessive meeting culture is prevalent, I wonder whether they have some fundamental problem getting on the same page. It may be that the situation has gotten out of control. There is a lot of work to do, so a lot of email is sent to coordinate. The email starts piling up and gets to a point where it becomes ignored (Your new motto: you can resend it if it is really important). This leads to more meetings to coordinate because nobody can keep up with the information flow. The meetings of course slow everything down tremendously, so even less time is spent asynchronously communicating via email. The situation starts feeding on itself, meetings become double and triple booked during office hours, and you end up doing your real work after hours. At this point people start really complaining, so meeting-free Friday is invented, until folks realize this is the only day you have a chance to schedule a meeting involving 3 or more people, and so an exception is made “once”. This is of course a slippery slope back to where you started from.

The situation is not as far-fetched as it might sound. I know a very well-known company in San Jose where this was the situation. Needless to say their current attrition rate is sky high.

Breaking the vicious cycle of highly synchronous work (”same-time” meetings and IM) and moving to a more sane environment of asynchronous work (email) is hard. It involves applying persuasion without face-to-face communication. I believe there are ways to do it, but it requires changing how teams interact - more about it in a follow-up posting.

We’ve been asked many times where the name Kalexo comes from.  Since every word in practically every language is already registered as a domain name, it is really hard to come up with a name.  When the company was founded, we did not know what we were going to build, so we were happy with company name that has no meaning to anyone.

The algorithm we used was:

1. Pick three consonants you “like”,
2. Order them randomly,
3. Append a random vowel to each consonant,
4. Check if registered, and iterate.

You will be surprised how many random jumbles generated by this mechanism are already registered.     Our if you are a Web 2.0 startup, pick a word that ends in “er”, and drop the “e”.

Kalexo is  the name of the software startup that I am involved with.  Our interest is how to better handle the mess of work that happens when a team grows large.  Getting on the same page and staying there is pretty hard when you have a large team and a few thousand things to do.  Over the last year or so, we’ve developed new ideas how to approach the problem, and we are using ourselves as guinea pigs.  As you can image, we also have quite a lot of things to do, and we run the company using our own tools.  If you have not heard of us before, it is because we’ve been busy building software.

Team-intelligence is the name of this blog,  which is about all sorts of interesting things related to teams, Silicon Valley, and of course news and progress reports from Kalexo.

Don Dodge is a clever guy - I used to run into him at AltaVista now and then. He has a interesting posting on his blog about how you should focus on your customers and not your competitors. Sort of in the same veign is the notion of stealth mode startups. Lets face it, having someone steal your big idea is unlikely mainly because it takes such an incredible effort to turn an idea into a business, and then you are still not ensured of success. Too many other factors go into a business in addition to the idea.

But I still run into folks that are surprised that we share our own startup ideas pretty openly with everyone that is interested. What we learned that is if you are interested enough to speak to us, you also likely have interesting ideas that we have not heard before. And sometimes we take those ideas and roll them into our own product. So you should really be more concerned about us taking something from you.