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.

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 !

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.

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.

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.

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.

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”.

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.