Q&A with Arun Kumar, CEO of Kerika, on How To Make Remote Teams Work
Remote and hybrid teams are on everyone’s minds right now, but the idea that you might need to work somewhere other than in the same room as your coworkers is not really new – it’s been around for ages.
Just think back to all the times you were in a day-long offsite, or working from home while waiting for the cable guy to show up, or simply traveling to visit a customer or attend a conference: you were effectively a remote worker during those times.
And think about the hurdles you faced when you were away from the cubicle farm, because you needed to get your work done, support your team, deal with managers and stakeholders, and make sure everyone was always on the same page in terms of what’s going, what’s getting done, and what’s at risk.
What’s different now is the scale of the problem, with some folks away for good (hello, Idaho!) and some folks in the office only a few days a week – and even these folks are not syncing when they are in the office, and when they are working from home.
Recently we spoke with Arun Kumar, founder and CEO of Kerika. Arun has been working on project management for 4 decades, and his experience with distributed and remote teams includes managing teams based in Europe, Latin America, and the Asia/Pacific region. He has been working with Agile techniques since 2006 when he introduced Scrum to a team at Microsoft.
You have been focusing on collaboration within distributed teams for over 10 years: what’s behind this long-term interest?
Long before I became an entrepreneur I was managing teams that were spread out across multiple continents, to deliver very complex solutions under challenging conditions.
Before starting Kerika, I led the creation and launch of Europe’s first cross-border stock exchange with an integrated backend. We went from 2 people in a room to a fully functioning, regulated stock exchange in just 9 months, by leveraging specialists based in New York, London and Stockholm.
After that I reflected upon my experience and concluded that geographically distributed teams were going to be the norm for a lot of companies even if they weren’t going to be as extreme as my experience! I was also taken aback by how frustrating it was to use a traditional “Waterfall”
approach to a project that was unlike anything that had been accomplished before – even the regulators didn’t know how to deal with the kind of new exchange we were proposing – and the fact that Microsoft Project, which was considered the gold standard for project management, was unhelpful throughout the experience.
I started thinking about this problem of collaboration and task management in distributed teams around 2002, and started Kerika.
What are some of the key differences that a project manager needs to be aware of when working with a distributed team?
Let’s start with the need for absolute clarity in communications, especially when your team is distributed across countries and includes people speaking different languages. We discovered that email was actually really terrible for this purpose: email sent to even a small group of people is guaranteed to go off track after just a few replies.
The next big problem is creating what we call the “box of work”: we need a container for each work item that contains within it everything about that work item, not just a basic description or stuff like who is assigned to the work and when it’s due, but also all the content that is relevant to the work, and all the communications that deals with that work.
This means making work items the center of it all: files, web links, conversations, etc.; all of this needs to live along with the work item, so when you pass the work to someone else, or simply go back to it after being away for a while, you can find in that container every single thing that’s relevant to the work item.
This means you shouldn’t have to search your Inbox to find all the mails that relate to a particular work item, or go searching through your document repository. That’s the old way, but that’s analogous to saying “Here’s a bunch of leaves, just put them back together to make the original tree and everything will make sense”.
This “box of work” is critical with remote teams, because you will have so little overlap with them. A team distributed between California and India, for example, will never have a minute of overlap in their workdays. Traditionally people tried to solve the problem with brute force: having daily Skype calls which meant that at least half the team had to permanently give up their evenings to get on these calls.
All of that is simply unsustainable: you will end up losing valuable employees.
If you want to successfully manage distributed teams, you need to really change your thinking about even the smallest things like “let’s get this done by the end of today”: whose “today” do you mean when you say that? Because the workday in India will end 12.5 hours before California, which means the Indian half of the team has already gone home before the Californians show up.
How has this thinking affected the design of Kerika?
Let me go back to my experience in building the first cross-border exchange and using Microsoft Project as my classic tool. There were huge problems with the traditional approach, starting with the fact that essential non-technical people are simply never going to be comfortable using a very techie-looking tool like Project. So while the most technical members of your team may be feeling OK with a hardcore tech tool, you are leaving behind a bunch of people who are slowly getting alienated and will soon be mentally checking out.
So we realized right away that the only “right” tool is one that is really inclusive in its design: everyone on the team, and everyone outside the team with an interest/stake in the team, has to be equally comfortable using the tool.
And, yet, it’s amazing to see so many of our competitors still going for the “made by techies, for techies” philosophy in their product designs.
Another big insight from my years as a project manager was that Agile approaches are essential to a wide variety of projects and environments. The thinking behind Kanban and Scrum boards isn’t only applicable to software teams: it’s equally useful for anyone, in any role, who needs to deal with uncertainty and change.
So when designing Kerika we thought hard about “how can we make it easy for people to subtly adopt Kanban, Scrum, and other Lean and Agile techniques, without going through any training, or even knowing what these terms mean?”.
I think we have succeeded on that front! It’s amazing to me to see middle-school kids in out of the way places like the Canary Islands (don’t feel bad, I had to look it up on Google Maps, too) use the same tool that people in Fortune 500 companies do.
You mentioned “no training”: are you saying that it’s not necessary to take courses in Scrum or Kanban to use something like Kerika?
I personally took training in Scrum, but I don’t think this kind of formal training is necessary for most people. We consider it to be our responsibility, as product designers, to build something that guides people, gently, down the path of Lean and Agile methodologies without making them feel inadequate at any point.
So we have designed our Task Boards for maximum flexibility; we don’t even call them Kanban Boards or Scrum Boards, because what people ultimately want is to get stuff done, which means knocking off tasks fast and well.
We have given training to some customers who came from very traditional environments with a command-and-control approach. We have customers working in government agencies who had no experience with being able to make changes to a common Task Board: they were used to having someone tell them exactly what to do, and when.
For these folks, our training has focused more on encouraging people to have more agency: go ahead and assign that task to yourself instead of waiting for your manager to do that; our tool makes it really easy to do that. Go ahead and move that task along on the workflow; if you make a mistake, it’s really easy to recover.
We take the learnings from our training to think again about how to make our product even easier to use.
There are a lot of task management tools out there; what’s your most important differentiator?
That would have to be our deep integration with Google Apps, which goes back to our first beta releases of Kerika, and to our similar integration with Box. Most of our competitors give some lip-service to the idea of integrating with Google Drive and Box, by adding a simple file-picker in their apps.
File-pickers will help you link in a file that’s already in your Google or Box account, but they do nothing to help with managing the access to that file. So if you simply link a file onto a Kanban board, it doesn’t mean your team members can also access it.
Kerika’s integration is at a deep API level with both Google and Box (and we will be adding Microsoft in the future): you can sign in with your Google or Box ID, and all your project files will be saved in your own Google Drive or Box account.
Just think about that! Your Kerika files are in your own cloud storage, under your control. IT departments love that about Kerika, because any policies they implement at a domain level, throughout their organizations, automatically apply to Kerika as well. If they don’t want a file to be shared with anyone outside their domain, for example, Kerika will not let you share the relevant board with anyone outside your company.
This API integration means that we do all the bookkeeping needed to make sure that everyone on your project teams gets exactly the right access to the right files. Add someone as a Team Member and they will instantly get read+write access to all the files for that particular board, and no other.
Change someone’s role on a board from Team Member to Visitor and instantly their access to that board’s files, which are stored in your own Google Drive, gets changed to read-only. You can even create new Google Docs or Box Notes from inside Kerika; you can’t do that with any other app.
This has a tremendous impact on productivity: people can’t believe how much of their time gets freed up when they start using Kerika.
One last point I would make is about scalability. A lot of our competitors have exuberant designs that look great when you have just a dozen cards on your board. But we are focusing on professional use, not tracking recipes or your errands. And professional work can mean dealing with many projects at the same time: you might be an active Board Admin on some boards and a passive Visitor on others. Kerika makes it really easy to stay on top of everything that’s going on with our unique Dashboard, which is more useful than anything you will find from our competitors.
Scaling also happens often within a single board: a long-standing team can quickly end up with a board with thousands of cards (hopefully, mostly in the Done column!) and if your tool isn’t designed like Kerika, you can quickly get overwhelmed. That’s where our unique Highlights feature comes into play.
What’s the next big thing for Kerika?
Given that we have users literally across the world, we are making a big push into supporting more languages. We are doing a soft trial with Hindi right now, and that’s looking good so we will be adding dozens more languages later this year.
We are also working on adding the same support for Microsoft login and Office 365 that we already have for Google and Box.
About Kerika
Kerika is task management for distributed and remote teams. You can learn more at kerika.com and start a free 30-day trial with all your coworkers.
Related Categories