Can the right person be guided to begin a career as a programmer in 12 months? Yes, I think so

In my experience, my Sri Lankan colleagues are some of the most reliable, responsible and dedicated professionals that I have ever worked with. 

If you value technical soundness, tenacity, and creativity, that is. For everything we say about how the modern education system educates creativity out of our children, I’ve found local talent to be some of the best when it comes to getting the job done. Good programmers know how to follow documentation and put things together, but great programmers look at what’s in front of them and figure out ingenious ways to build something totally new. The latter is the common thread which binds every great programmer the world has ever known. 

Tech – The great catalyst for Sri Lanka

While the country awaits a deal with the IMF, I believe tech can be a powerful tool through which the economy can stage a rapid recovery. Sri Lanka’s IT industry doubled between 2015 and 2020, both in terms of revenue and the size of the workforce. By 2030, the industry could very well generate over US $ 6 billion in revenue, if it plays its cards right. Also, consider this: The total investment to produce a graduate amounts to nearly LKR 1.6 million (i.e. the cost of a bachelor’s degree from a private institute). But, the value each IT professional can generate in a single calendar year alone is many multiples of that. Not many industries can boast of such great investment dynamics (Source).

Imagine how much better things could be if we could reduce the cost and time taken to produce a tech grad, so that they can at least have a foot in the door?

The two choices before us

Now, there are two ways to get things moving in the right direction. You can push for top-down change (i.e. at the policy level), or get things going at the grassroots level. The former is necessary though time-consuming, but the latter is very much doable. And if the results are good enough, pushing for policy-level change will be so much easier.

That is why as a company, we launched Calcey Springboard.

Springboard is a 12-month, fully-funded coding bootcamp we’ve put together to support talented students get into tech. Calcey’s own engineers will guide them while they learn from a globally recognised curriculum of MOOCs, and they will be tested each semester by us. Once they graduate, they can seek out an internship at any company they like!

We chose to put together a curriculum consisting of MOOCs simply because they’re proven, recognised, and are of a high standard. We’ve vetted them personally and can vouch for their quality. Sometimes, we even use them to train our own people on emerging technologies.

Why are we doing this?

The way we see it, we are simply giving back to society and doing our part to widen the pool of tech talent in Sri Lanka. We owe a debt of gratitude to Sri Lanka’s public education system which produced the awesome people who built Calcey into what it is today, and this is our way of paying back our dues.

Now that you know the what, the why, and the how behind Springboard, I have one more favor to ask you. We want to make sure we can award as many scholarships as we possibly can, and would be really glad if you could spread the word. Applications close on November 30th, which means whoever wishes to apply has 15 more days to do so. 

Apply for a Springboard scholarship at !


Mangala Karunaratne is the Founder and CEO of Calcey.

Life at CalceyOpinion

Why did we peg salaries to the dollar?

A few weeks ago, we gave our people the opportunity to have their salaries pegged to the US dollar. It turned more than a few heads, and lots of people asked us why we did so.

I also saw a fair share of criticism from some people. I don’t know why, so my knee-jerk reaction would have been to respond with something like this:

However, now that I’m older and (hopefully) wiser, I slept over it, and decided to write this blog post instead.

Why did we peg salaries to the dollar? Simply because it was the right thing to do.

“To avoid criticism do nothing, say nothing, be nothing” – Elbert Hubbard

Sri Lanka is home to our development center. The country’s economy is going through a really rough patch at the moment. And with inflation hitting all time highs even in the US, I don’t need to tell you how a frontier market like Sri Lanka is doing.

Raghuram Rajan, (Economist, Professor at Chicago Booth, and one time RBI Governor) once said that inflation is a tax which affects the poor the worst. He’s right. Inflation reduces your disposable income while you sleep. 

As a founder, I don’t want our people to feel the heat of rising prices, just because a central banker or politician miles away is bad at his job. And companies with unhappy people don’t stay in business for too long either.

As an exporter of services, Calcey benefits from a depreciating rupee as we bill in dollars and pay in rupees. By giving our people the option to peg their salaries to the US dollar, all we’re doing is sharing the benefit we gain from a depreciating currency with our team so they may sleep easy at night. Our salary pegging scheme is entirely voluntary, and we went so far as to offer it to all current employees who originally didn’t opt-in to the pegged salary scheme. We let them opt-in even after the Sri Lankan rupee was devalued overnight. At Calcey, we absolutely love the talented rock stars who work with us.

Calcey has a flat hierarchy and a no B.S. culture. The request for inflation-protected salaries first came from our own employees, and we acted fast to respond. We take so much pride in buying fair trade products, so why shouldn’t an employer show that same sense of fairness to its people? After all, they’re the reason we’ve been in business for the last two decades.

The main reason why we opted to peg salaries is because local labor laws prohibit us from paying people in other currencies. Even if we somehow found a way, those funds will still be subject to mandatory conversion rules. By pegging salaries, people will still get all their statutory benefit payments while their incomes are protected from inflation. Win-win!

We’re proud that we’ve been able to do this at Calcey, and we will gladly shout about it from the rooftops. If all employers in Sri Lanka decide to do this, we will be overjoyed about being able to blaze a trail in our own little way. We hope all peers who follow our path apply the pre-devaluation exchange rate to calculate base salaries in the interest of fairness.

If you’re reading this, and you don’t work at Calcey (yet), I invite you to come join us. We’re hiring! If you join us before May, your base salary (for pegging purposes) will be calculated at the pre-depreciation rate of 198.50. We will also let you work on multiple awesome projects in a flexible, remote-first work culture, and much more ✌


Mangala Karunaratne is the founder and CEO of Calcey Technologies.


Developing an app? Here’s how to choose between an in-house and a remote development team

When building a tech company every founder and CTO needs to decide how they will structure their tech team. The options available are fairly well established.

  • Hire developers that work with you in your office (in-house team)
  • Hire developers who will work from home (remote team)
  • Hire a team of developers provided by an external software development agency. Often such agencies would be off-shore and hence work remotely with you

What’s best for you? The short answer is – it depends. The cost will play an important role in this decision, but there are several non-quantifiable factors you need to consider too. If you’d like to compare the likely cost of an in-house team vs a remote team provided by an agency we’ve broken down the costs of an in-house dev team in New York here. Here’s everything else you need to consider, other than cost/budgets;

  1. Can you attract the best local talent? 

There is a huge difference between a 10x developer vs a journeyman. This is relevant with anything, not just software development. But, software by nature has strong asymmetric returns. For example— a brilliant developer may singlehandedly create an MVP of a product that goes on to become a billion-dollar company, while a mediocre developer may write a lot of code that simply gets scrapped. The time and effort put in may not be different but the end results may vary wildly. In software, as in many other fields with asymmetric returns, the best talent isn’t only a fraction better than the mediocre players. What they produce is exponentially better in value. 

The question at hand is ‘Are you going to attract the best talent in your locality?’ If you’re based in a tech hub, your chances of acquiring that top talent will likely be low when you compete with giants like Google, Amazon, and Facebook.  But you shouldn’t be discouraged. Rather than sticking to your locality, make the whole world your hiring market. Go remote. 

2. Is speed your priority? 

Studies show thatthe average hiring time for a software development engineer in 2017 was 41 days“.  On top of recruitment time, A typical team needs to go through a process of team development i.e. forming, norming, storming, and performing, before they can operate at peak levels.  If you’re in a race against time to get to market ahead of the competition, hiring a ‘ready-made team’ from an external agency will help you avoid these obstacles altogether. When time is of the essence, a team from an agency with a prior working history will always reach the ‘performing’ stage faster and you’ll end up saving months in recruitment time too.

3. Lean and focused teams are in

Auren Hoffman is right when he says that “Almost every company spends over 95% of its time doing what every other company does. And it spends less than 5% of its time on things that are unique to the company. This makes no sense.” It’s a well-known fact that larger teams move slower and are harder to coordinate compared to smaller teams. Simply keeping everyone on the same page (more difficult than you’d expect in the highly dynamic world of technology) becomes an almost impossible task as team size grows. At Calcey  we are huge fans of Jeff Bezos’ ‘two pizza teams’ concept and we organize our software development teams accordingly. 

So how can you keep your core team lean and focused? You outsource through external agencies for everything other than for the few key core competencies that make your business unique. Surprisingly, software development doesn’t fall into this category even at some tech companies. Sometimes, their core competency may very well be product design, branding, and customer relationship management. 

4. How specialized is your business domain?

If you’re in a niche, complex business and your software project requires a deep understanding of your domain, then opting for an in-house software development team makes sense. They can learn and absorb your business domain over time rather than forcing you to spend considerable time and energy teaching an outsourced software development team about your business. You would also not be able to directly control churn within your remote development provider’s team and hence may need to repeat this onboarding process again and again if too many experienced hands leave the team.

5. Are you willing to invest in a team?

What’s the type of team that comes to your mind when you think of developing software?  Do you imagine a team made up of 3 or 4 developers? Or a team with developers and other supporting roles such as PMs, Software Architects, and QA engineers? Just a couple of developers might do when you’re starting out and only looking to create a scrappy MVP. But once you need to operate at scale; serve a sizable user base and integrate with 3rd party apps in your ecosystem etc. this bare-bones team will quickly reach its limits. At that point, it would be time to bring in the supporting roles and get your developers who were previously shipping code at abandon, accustomed to industry-standard development practices. This isn’t always an easy transition, and any technical debt created by your original developers would be exposed and will need to be fixed. 

If you’d rather avoid these growing pains or don’t want to invest to create a fully-fledged development team, it makes sense to go with a remote development agency that can provide a fully-fledged team that can manage the full software development life cycle from day one.

6. How much flexibility do you need?

Software products often need to change tech stacks as they mature. Furthermore, development may have to speed up and slow down at different points of time. If you opt for an in-house team it’s worth considering how you will manage such changes. Can your team re-skill when you need to change tech stacks? Will you be able to hire quickly when you need to speed up development and have flexible staffing arrangements in place to ramp down the team when you slow down?

Often this is where an external agency will shine. Their business model revolves around managing staffing requests and serving clients using a variety of technologies. So flexibility and versatility are often baked into their mindset and contracts.

7. You don’t know what you don’t know

When confronting a challenge your solutions are typically generated by your prior experiences. It’s very likely that there are better solutions out there, but we can only consider a sub-set out of these solutions— those that we know of. So what does this mean? Simply put, the broader your perspective the better. 

Having a broad perspective is easier said than done in the dynamic world of technology. The industry evolves at a breakneck pace and new frameworks, libraries, and tools are constantly introduced. How many of these latest and greatest tools we are exposed to depends on how often we are faced with the novel, fresh challenges. Ideally, a highly motivated developer would keep in touch with the latest developments, but given the pace of change in the industry, this is impossible. So necessity is a better driver of learning. 

What all this means is that an in-house tech team that is embedded in one business domain and a narrow technology stack will often have a narrower perspective and idea set in comparison to an outsourced agency which is more versatile due to the nature of their business.  

Principally, both approaches to software development are beneficial, however, their effectiveness can vary depending on the situation. Remote development comes at the benefit of providing a broader, more versatile team while in-house development gives your developers a deeper understanding of the project.  On the other hand, in-house teams come with the headache of time spent on recruiting and finding people with the right ambitions to help the company in their core business functions. The added benefit of having a remote development team is they often have more flexibility which is better than having less. Which option you go with depends on your own unique circumstances, but whatever it is, choose wisely.

Cover image credits: Unsplash/@wocintechchat


What to expect when you work with us

We love building great software. That means doing a few things differently 

At Calcey, we develop software. We are a boutique development outfit with an office in Colombo, Sri Lanka. But we are also not your typical software development company. We prefer to think of ourselves as providers of small, extended remote teams for global clients in need of software development services.

Developing software is not like selling a commodity. People matter. Quality matters. When the two meet, magic happens. To build good software, the interests of a developer must align with those of a client. Anything less is a huge no-no.

If you’re a developer just starting out in your career… 

One of the best and fastest ways to sharpen your skills and grow is to work in a small team, and on a challenging project for some time. This helps you develop a deep mastery in a given area, while preventing your effort from being buried under that of a hundred others. Deep mastery equals better learning, and higher visibility equals faster promotions, all else remaining equal. Of course, when the time is right, you should choose to move between teams to learn new tech stacks and skills. This is one advantage service companies like ours have over product companies. At Calcey, we have the ability to give our developers the chance to attain deep mastery and upgrade their skills with time by moving between teams if necessary. But at a product company, developers are often doomed to work on one part of a software forever.

On the other hand, if you’re a client…

You must look to work with a small, stable team that you can get to know with time, so that everyone can quickly develop a sense of camaraderie and start working towards a common goal. An organic relationship built this way allows for developers to become emotionally invested in your product, and allows them to take ownership and drive the process forward, instead of you having to push from behind with all your might. A small, stable team is inherently better at getting people to work together than a large, sprawling one. That’s why a certain Jeff Bezos prefers two-pizza teams.

A remote extended team will also allow you to reap the benefit of working with a group of developers who almost feel like your own, without taking the financial risk of actually hiring them and sinking a significant amount of capital into it.

Our approach…

Simply brings these two elements together to create a system that keeps everyone happy. Developers get to work on interesting things, while clients receive top-notch projects, finished and delivered on time. It also aligns our incentives with those of our clients. As we ship more and more successful projects, our clients can grow their businesses. That growth in turn comes back to us in the form of more projects, and we get to hire more people to work on them. Basically, it’s a virtuous cycle that everyone benefits from. This model has worked so well for us that we’ve managed to grow completely organically from a 2 person startup to a 140-strong team.

Henrik Palmquist is the CTO of, one of the largest online fashion retailers in the Nordic region. has been a client of ours for the last 3 years, and has benefited immensely from this extended remote teams model we’ve staked our reputation on. Here’s how Henrik felt about his experience working with us.

There are also a few other things that you ought to know about us, which we consider key pillars of the Calcey Way.


We like to give our clients a high level of visibility into their projects. The more our engineering teams and our clients know about each other, the better, as it eliminates room for misunderstandings, and stops people from feeling like they don’t belong. Before COVID-19 took airplanes out of the sky, we encouraged our clients to come visit us in Colombo and get to know the team that would be working for them. They could have a team workshop and do a deep dive into the client’s domain or business challenge, or simply go out for dinner or on a trip around Sri Lanka. We encourage such visits and face-time because we know that is how the seeds of a great relationship are sown.

That’s not all though. Once the project is in progress, clients are free to join daily stand-up meetings and even talk directly to our project managers and developers. Here at Calcey, there are no middle men or lengthy email chains that make you want to rage-quit. Instead, we have actual, normal, and reasonable human beings who’d be always happy to get on a call with you and walk you through how your project is going, what we’d be doing next, what works, and (most importantly) what doesn’t.

Mikke, the CEO of Ancon—a Swedish firm that develops software for the restaurant industry, is someone who has visited our offices many times in the past to hang out with our developers. He was pleasantly surprised by how well our team got along with his, and had some nice things to say about us.

Straight talk all the way

At Calcey, each and every individual is encouraged to tell it like it is, politely and with respect for each other. No beating around the bush, and no false platitudes. Humans sometimes have the tendency to downplay things (or let them slide completely) in the hope of not upsetting the proverbial apple cart, but that doesn’t really help anyone. This is particularly true in our case, where we end up working with clients from different cultures with wildly differing levels of technical understanding. Being straight with the facts has helped us bridge these differences and made it so much easier to form trusting, mutually beneficial relationships.

As developers, sometimes we find ourselves in a position where we can clearly see that the approach a client is planning to take won’t help them achieve their goals. When we run into such situations, we encourage our developers to actually speak up, challenge the client’s assumptions where relevant, and put forward better approaches or suggestions. This can often happen when clients don’t come from a technical background, as Joanna and Lucy, co-founders of The Oneness Movement found out. Luckily, our team was on hand to help them navigate the confusing maze that technology can sometimes be.

Take ownership

Whether its a simple dashboard or a fully fledged enterprise app, we approach every project as if it was our own. When an outsourced development services provider doesn’t take ownership in their work, it naturally breeds a short-termist attitude where the focus is on delivering the project, billing the client, savouring that ‘ka-ching!’ and moving on. Things like strategic fit and future-proofing go out the window.

Instead, we like to think like product owners and take the long term view. This motivates us to flag issues as soon as they arise, and suggest features and fixes which we think would be helpful over the long run. For instance, if a client tells us to build a native android app, we would always try to find out if there would ever be a need for an iOS app as well. If there is, we would always take the time to suggest the option of building a react native app instead, which suits both dominant smartphone platforms thus saving time and money over the long run. If we don’t, the relationship we have with the client will be in tatters once the client realises that they’ve been taken for a ride.

When Compare Networks came to us to help them build an enterprise sales app for the biotech sector, they probably thought we would build it, ship it, and be done with it. Instead, we naturally took ownership of the project, and helped them envision the entire feature roadmap of the product. Our developers took the time to understand the mindset of the end user and empathise with them in order to make the features of the app very easy to use and understand.

Bespoke teams

The composition of engineering teams at Calcey tends to be flexible, and is always geared to meet a client’s evolving needs. Instead of having projects transferred between teams like a weird game of musical chairs, our clients get to work with the exact same core team while a few additional specialists will be brought in as and when required. For instance, a client who comes to us with the intention of developing an MVP might only need a small team to get things started. Later, when it is time to build a functioning app, the team might need a few more engineers and designers whom we can bring into the team. Eventually, if the app has to be scaled to accommodate millions of users, the team will need the services of architects and other experts whom we will draft into the team.

That is how we helped a London-based startup, Fresh Fitness Food (FFF), evolve from a fledgling meal delivery service to a global fit-tech company that is driven by technology. After all, we were once a startup too and know what it is like to try and achieve product-market fit and get a steady stream of cash trickling through the door. Over the years, FFF has been able to rely on us to shape and develop their product, business strategy and more. As FFF’s needs evolved, the composition of the Calcey team supporting them also evolved in tandem, thus ensuring that all the development resources FFF needed were always at its disposal.

Do the right thing, always

To this day, all new clients knock on our doors thanks to direct referrals from existing clients. We consider this to be a signal that we are doing something right. It also serves as an incentive for us to safeguard our reputation in the business, because one disgruntled customer is all that it would take to bring down the house that we so painstakingly built. That is why we always try to do what is right. Sometimes, that means saying ‘No’ to a client if we feel that we are ill-equipped to take on a job. At other times, it means making accommodations to suit talented and deserving employees, who may be going through tough times in their personal lives.

This ethos of doing the right thing has helped us cultivate a pool of happy clients and loyal employees, both extremely crucial for our success. Perhaps that is why our NPS scores have been consistently high, despite COVID-19 upending the way we live, work, and move. Over the last three quarters, our Net Promoter Score (NPS) has been on the rise, and hit an all time high of 78% despite all of us being forced to work from home due to the pandemic. Achieving this kind of NPS rating places us squarely amongst some of the best software development companies in the world, and leaves us feeling very optimistic about the future.

Should you be on the lookout for a reliable and agile software development partner for your business, don’t hesitate to get in touch with us through our website. Our client onboarding team will reach out to you in no time ?.


No Time To Ride: Uber Sri Lanka’s Automation Debacle

Learn from an unhelpful chatbot and build a better customer support system for your business

Uber Sri Lanka is in the news again, this time for turning a blind eye to the issue of an errant driver assaulting a customer over an innocent question about a cancelled trip. To make things worse, Uber Sri Lanka has done nothing to rectify the situation after the passengers took to social media, leaving its chatbots to spew pre-programmed messages instead. Understandably, this has infuriated many, and questions are being raised about the legality of Uber’s operation in Sri Lanka, where there is no formal channel for unsatisfied customers to raise their grievances.

Sri Lankan users have been voicing complaints regarding Uber, but to no avail/ Source: Twitter

Customer care has been hailed as an area which chatbots can excel, rendering customer support executives a thing of the past. However, as is visible with the Uber Sri Lanka debacle, a chatbot can sometimes do more harm than good.

In such a backdrop, what should you be aware of if you’re thinking about deploying a chatbot to solve your business problems?

Understand The Different Types of Chatbots

Chatbots can be categorised into two primary categories: ‘Transactional Chatbots’ and ‘Knowledge Chatbots. Before you deploy a chatbot in your business, make sure you understand what each type of chatbot can and can’t do. Deploying a transactional chatbot in a place which needs a knowledge chatbot is a recipe for disaster.

Transactional Chatbots are built and optimised to execute a limited amount of specialised processes which eliminate the need to talk to an expert or use more complicated UIs such as mobile apps or websites. In contrast, knowledge chatbot support thousands of processes and in some cases, can even make decisions for you.

Transactional chatbots are trained on top of structured data and can do a set of limited operations. Think of what a bank operator can do for you over the phone: verify your identity, block your stolen credit card, give you the working hours of nearby branches and confirm an outgoing transfer. The exact same functionality can be imparted to a transactional chatbot, which can then be deployed via Facebook Messenger, for instance.

On the other hand, knowledge bots are helping you both make a decision and execute it. In order to be able to “make a decision” the chatbot is usually trained with a vast amount of unstructured and structured data, and is trying to produce a response as an expert. Though not exactly bots, IBM Watson (and Deep Blue before it) are good examples of knowledge systems.

A matrix showing the differences between knowledge chatbots and transactional chatbots / Source:

Simple, But Not Stupid

For a chatbot to truly deliver value, it must simultaneously be simple to use, while not being too simplistic a.k.a. ‘stupid’ to turn away and/or frustrate users. This is a problem Uber Sri Lanka has to deal with. Remember that a chatbot is not sentient, and is only as good as its bank of pre-programmed scenarios. When a query doesn’t match a pre-programmed scenario, the bot gets stuck in a loop and users get frustrated.

When a chatbot gets stuck in a loop, user frustration is not too far away / Credits:

A casual scroll on Twitter is enough to get a sense of how quickly the average Sri Lankan Uber rider is frustrated by the misplaced efforts of the chatbot.

Disgruntled Uber users are not hard to find in Sri Lanka / Source: Twitter

This is where sophisticated Natural Language Processing systems come in. Microsoft, Amazon, and Facebook already provide state of the art Natural Language Processing (NLP) developer tools to help your bot understand user intents, so whenever you deploy a chatbot, make sure the chatbot is built to benefit from these powerful NLP engines.

Know What You Will Pay

Nobody likes hefty bills of eye-popping amounts. It pays (in this case, literally) to understand how your chatbot vendor will charge you for your chatbot.

Generally, enterprise-level chatbot platforms use one of the following pricing models:

Subscription: Build limited or unlimited bots for a flat monthly or annual fee. This is probably the most suitable model for an enterprise.

Pay per usage: The platform cost is based on chatbot usage and the number of API calls. This model can provide you with a higher degree of flexibility allowing you to scale gradually.

Pay based on performance: The platform cost is based on how the chatbot performs against goals agreed between the customer and vendor. For example, a successful interaction between the bot and the client, which leads to a signup, is considered as a paid conversation, regardless of the length of the chat. Under this model, enterprises will be charged accordingly to the goals achieved.

Don’t Underestimate Humans

Chatbots may be better and more efficient at a range of things, but they cannot beat a human at one thing: displaying empathy. Therefore, depending on the function of a chatbot, it becomes important to ensure that a human is available to step in and takes over a user interaction if things get out of hand. After all, even the most experienced support agent often requires a second opinion and your chatbot is no different. That is why it is recommended to follow a bot-human hybrid model, which allows a human to takeover an interaction depending on the complexity and criticality of the issue.

To understand this issue in detail, take a look at the two screenshots below. In both cases, the triggering keyword is “server failure”. In the first case, the user simply wants information about the precautionary measures in case of a server failure, while in the second case the user wants to report the occurrence of a server failure.

Same keywords, but different questions entirely. How the chatbots responds is important /Credits:

What are your views on chatbots? Who has deployed chatbots well and who hasn’t? Let us know your thoughts below!

Cover image credits: COPREUS


Lessons From The ‘Skype Way’

Image credits: TechBeat

Skype, at one time the favourite Peer-2-Peer (P2P) calling service of a generation raised on MSN Messenger, can be termed the precursor to the myriad social messaging and networking apps we have on our phones today. First released in 2003, Skype eventually went on to upend the international call market. By 2014, Skype accounted for nearly 40% of the international call market. In other words, by 2014, nearly 214 billion minutes of calls were being made through Skype.

What helped Skype morph into the behemoth it became? And what can others learn from their story? Read on to find out.

It’s All About The Team

The success of an early stage startup is very much down to its founding team and the dynamics between them. The founding team behind Skype looked nothing like the typical MacBook toting, ‘Silicon Valley Startup Guy’ types we’ve come to know and recognise in recent years. Instead, Skype’s founders were..rather ordinary, but a well functioning unit with complementary skills. First there was Niklas Zennström, a Swede who was employee No.23 at Swedish telco Tele2. Then there was Janus Friis, a Dane who worked his way up in customer service for a Danish telecom operator. Programming was the responsibility of Jaan Tallinn, Ahti Heinla, and Priit Kasesalu, Estonian schoolmates who once learned PHP over a weekend in order to win a coding assignment for Tele2 (where Niklas also worked). Rounding out this team was Toivo Annus, who was well versed in project management.

The perfect combination of skills to build a product!

The Skype team from its early days/ Credits:

Just Because You Fail, Don’t Throw The Baby Out With The Bathwater

Not many know that Skype was actually born out of the remnants of a previous product– Kazaa, which was built by this founding sextet. A P2P file sharing platform similar to Napster, but without the requirement for an intermediary server, the founding team envisioned Kazaa to be everything Napster was not. This meant staying on the right side of the law, and creating a better, faster backend.

It didn’t take long for Kazaa to succeed. Within a very short time after its launch in September 2000, Kazaa became the most downloaded program on the internet, picking up users at the rate of one per second.

Then came trouble.

Like Napster before it, Kazaa also found itself on the wrong side of the law. But not for lack of trying. Zennström and Friis tried, and failed, to seal a deal with US film and music companies. Lawsuits started raining on them, and the team found itself hiding from an army of ferocious US lawyers. Some of the attempts to haul the Kazaa team in front of the law are so mind-boggling that they deserve to be included in a Hollywood movie. Take for instance the time when Zennström went to see a play at a Stockholm theater and was approached by a stranger. The individual is said to have handed Zennström’s wife a bunch of flowers and held out an envelope containing a summons for Zennström. The Swede made a run for it; the summons failed to be duly delivered. He was similarly pursued in London, this time by a motorcycle, but Zennström managed to give the messenger the slip.

Having eventually made peace with the film companies and music labels, the Kazaa team looked at a new, but less legally fraught outlet for their new P2P technology. The founders had been smart enough to isolate Kazaa’s intellectual property in a shell company based in the British Virgin Islands. As they toyed with various ideas at a local bar, Annus and Friis had their “eureka!” moment—they could make voice calls cheap and easy by sharing data peer to peer just as Kazaa did. They even talked about creating Wi-Fi phones, an idea that would later be implemented in Skype. In the spring of 2003, an early alpha was coded and shared for testing with about 20 people.

The Skype team preparing to launch Skype 1.0/ Credits:

The name of the project originated from the words “sky” and “peer.” Following the example of Napster and others, the name was shortened to “Skyper.” But because the domain was already taken, the ‘r’ was shaved off. “Skype” it was.

Beta Testers Can Be Wrong Too

To a devout follower of the ‘Lean Startup’ methodology, there is no way forward except through MVPs and beta testing. In principle, this is not a bad idea at all. But sometimes, the initial feedback you receive can be worthless. Just ask the Skype team.

When Skype was first released, talking to a computer was seen as an extremely silly thing to do— as silly as talking to your hand did when mobile phones first appeared. Feedback on the initial version of Skype was not exactly enthusiastic. The sound was glitchy, for instance. But when testers realized that they could now speak via computer to people on the other side of the world for free, attitudes change. The key however, is to make sure customers understand your entire value proposition.

Simple Is Beautiful

One of the biggest drivers of Skype’s early success was the simplicity of the app. The team did a fine job of making the technology easy to use, and the friendly, soothing UI didn’t scare away anyone. Careful attention was paid to ensure that unlike other services, Skype slipped easily through firewalls. The program left no footprints on the Internet, call quality was great, and the service worked like a charm. Right from the beginning, Skype’s product managers were clear in their vision to make sure Skype remained usable to everyone. “Right from the start we set out to write a program simple enough to be installed and used by a soccer mom with no knowledge of firewalls, IP addresses, or other technological terms,” proclaimed one of the early Skype employees, Lauri Tepandi.

Skype shipped with a friendly, easy to use UI /Credits:

Embrace Constraints

From the time it launched, Skype captured the attention of investors thanks to its ability to scale fast and ship new features at astonishing speed, with a small team of around 20 employees. On its first day of launch, Skype was downloaded by 10,000 people. Within a couple of months, it already had one million users. Throughout this time, Skype rarely faced a service outage. The key to this solid performance was Skype’s tech team, who weren’t in the habit of flinching in the face of adversity. Even though they lacked many resources, Skype’s tech team was forever confident of their skills and creativity in deploying code.

Steve Jurvetson, an early investor in Skype remarked “I remember wondering: how can they be so good? How can such a small group can do so much so quickly, compared to typical development efforts in, for example, Microsoft? I had the impression that maybe coming out of a time of Soviet occupation, when computers were underpowered, you had to know how to really program, effectively, parsimoniously, being very elegant in sculpting the programming code to be tight, effective, and fast. [That’s] not like in Microsoft, which has a very lazy programming environment, where programs are created that have memory leaks and all sorts of problems, that crash all the time and no one really cares—because it’s Microsoft!”

Skype surpasses 10 million users much faster than any service before it /Credits: Steve Jurvetson

Jurvetson was right about the Skype team’s talent. Priit Kasesalu, one of the tech whiz’s in the Skype Six (as they are now referred to), is just one example of how talented Skype’s tech team were. A high school friend of Jaan Tallinn, Kasesalu hacked modems as early as the Soviet era at the House of Young Technicians, and is a game fanatic whose home is ‘filled with servers’. According to a famous anecdote often heard in the Skype offices, when Tallinn and others argue about the technological feasibility of some kind of mechanism, Kasesalu usually comes to them and says, “Stop, I’ve figured it out.”

Do Away With The B.S.

Skype’s founding culture, one which did away with the superfluous in favour of practicality and straightforwardness, was another key driver of growth for the company. New ideas were welcomed with open arms, and there were countless instances where ideas were programmed into a product the moment they popped into someone’s mind. Some coder would have an idea in the morning and by the same evening it might already have 10,000 users.

When the price list was being drafted for Skype Out, a service which would allow users to make Skype calls to telephone networks, the Skype team didn’t bother with market research. After all, they were launching something completely new. There was no precedent, and nowhere to go look for data on how much people would be willing to pay. Instead, two Skype employees devised the list in one night, using nothing but Excel. This may not be the best approach to follow at all times. But the point is that you don’t have to overcomplicate things (and beware of analysis paralysis).

Skype’s ‘No B.S. approach’ (which we at Calcey also love and preach) permeated throughout the company. Every week, five to ten 10 employees joined the company. The screening system was simple and very much the product of Toivo Annus, one of the founders who was incharge of global development. You were hired if you passed the test assignment. Wage negotiations were often redundant—if you deserved to be in the company, you’d be paid what you needed.

Skype’s culture attracted employees from far and wide. Eileen Burbidge, an American, ditched Yahoo and Silicon Valley to come and work for Skype. Burbidge was taken aback by the Skype culture, but in a good way. “Having just come from 11 straight years of working in Silicon Valley, I was super impressed and actually amazed that these technical leaders seemed not to have any ego at all, didn’t care about titles, didn’t care about roles or pointing fingers and were all insanely committed to seeing the ‘project which had turned into a company succeed,” said Burbidge. “They had a sense of responsibility and discipline that I had never witnessed before.”

Eileen Burbidge at a TechCrunch Disrupt event in London /Credits:

Used to American small talk, Burbidge quickly realized it would not work in this environment.

“I was used to greeting people with a ‘ping’ or a ‘you there?’ followed by a ‘how are you?,’ ‘having a good day?,’ ‘am I interrupting?,’ or ‘can I ask you a question?’ But for Toivo all of this was superfluous and simply needless cycles. He would just reply with one word: ‘Ask.’” Burbidge told VentureBeat. Of course, Toivo and the rest of the Skype team were not being rude towards Burbidge. It was just that with English being a second language for most employees in Skype’s Tallinn headquarters, many didn’t possess the vocabulary to engage in pointless small talk. According to Burbidge, now a partner at London-based Passion Capital, this was a coincidence that ended up being very good for Skype’s culture.

Thanks in large part to its culture, and scrappy, ‘never say die’ attitude, Skype’s success paid off handsomely for most of the company’s initial employees and investors. In 2005, eBay agreed to acquire Skype for USD 2.5 billion in cash and eBay stock. Then in 2009, eBay divested Skype to a consortium of investors including Silver Lake, Andreessen Horowtiz, and the Canada Pension Plan Investment Board for US$1.9 billion, valuing Skype at US$2.75 billion.

Then came the announcement to top them all.

In 2011, Microsoft acquired Skype for USD 8.5 billion…in CASH. At the time, the deal was perhaps the largest carried out by Microsoft, and rightfully turned many a head. But how Skype has fared since then is a story for another day.

Today, Skype may be a shadow of its former self, a company in decline even. But that’s very much part and parcel of a company’s lifecycle. However, the lessons startups and founders can learn from Skype’s early days, will forever remain invaluable.


Bringing Calm To The Valley: Lessons From Alex Tew

How one man learned to build things that matter, the hard way.

Alex Tew’s name may not ring a bell to Gen-Zers today, but for Millennials and the generations before them, Tew’s story is the stuff movies are made of. Venture capital funded growth and stock exchange listings didn’t mean anything to Tew. He just wanted to make money, quick, and that’s exactly what he did. At 21, Tew was a millionaire. And it took him only 4 months to get there!

Meet Alex Tew /Credit:

Then he became depressed.

Then he made it big, again.


And what lessons can we learn from Tew’s story?

Striking Gold and Post-success Depression

One late night in August 2005, Tew was in his room, wondering how he was going to pay off his student loans. At the time, he had just enrolled in business school at the University of Nottingham. Tew decided to brainstorm cheap things he could sell a million of. He managed to come up with a few ideas, including one for a questionable product called the ‘Gum Slinger’, which was basically a small pouch for used chewing gum.

Then he struck gold: Tew decided to start a web page with a million pixels that could be purchased for $1 apiece.

Today, this idea would have been laughable. But remember, this was 2005, and the internet as we know it today was still in its infancy. MSN Messenger ruled supreme, and internet advertising was a virtual mirror of the Wild West.

Two days and $50 in domain fees later, the Million Dollar Homepage was born.

Tew’s concept was extremely simple. For a minimum of $100, an advertiser could buy a 100-pixel block (10 x 10 grid) and display an image or logo of their choosing, with a hyperlink. The only guideline was that it couldn’t be porn.

Tew managed to successfully sell 4.7k pixels to friends and family, and he used the money to hire a PR agency to draft a press release. The release was picked up by the BBC and The Guardian, and advertisers started buying up pixels on his site.

The evolution of

One month in, Tew had raked in $250k, and was receiving 65k hits per day. By the end of October, he’d made $500k from more than 1.4k advertisers. Come New Year’s Eve, 999k pixels had been purchased. Tew auctioned off the last 1k on eBay; bid $38k, bringing his grand total to $1.04m

After paying the tax man his fair share, Tew was left with nearly $700k to his name. He promptly dropped out of college and moved to London. Over the next four years, Tew tried to replicate his initial success by launching various different ventures. But it was all in vain.

Lesson 1: Provide Value, Don’t Demand Attention

Success can be like a treadmill. Once you achieve a certain amount of it, there comes an insatiable hunger for more. This can trick people into focusing their energies on creating things whose success entirely depends on virality or fame. Instead, Tew argues that you must focus on building things which actually enhance someone’s quality of life i.e. provide value. “Success can actually be bad, and can teach you the wrong things. I was thinking about ideas that would get attention instead of provide value” says Tew.

Unable to replicate the success he had with the Million Dollar Homepage, Tew moved to San Francisco and joined a friend’s startup incubator.

Lesson 2: Look To Your Own Problems To Find Your Next Idea

The four years he spent looking for his next big idea (2006-2010) took a toll on Tew. He didn’t eat or sleep well, and his mental health took a toll. Till then a lifelong meditator, Tew found himself slowly drifting away from his daily practice. Tew realised that he had to initiate some corrective he built another website. The result was, a simple website with a 2-minute timer that would restart if you moved your cursor. It was Tew’s way of forcing himself to meditate.

The timing was perfect. The rise of the internet and the proliferation of smartphones had brought with it loads of ‘mental clutter’ and people were starting to talk about digital detoxes. Questions were being asked about the long term impact of social media on one’s mental health, and the practice of mindfulness was having its moment.

According to Google Trends, search interest in mindfulness has continued to grow

Lesson 3: Take Your Time To Build

Alex was in no hurry. He built in 2010. He took the next two years to figure out what he was going to do with it. In 2012, he finalised his plan to build a more robust meditation app.

Finding the seed money wasn’t easy and Tew was laughed out of many meetings. “When you talk about meditation with people who don’t meditate, and who work in tech, it’s so far outside of their world of focus” he says.

Tew eventually managed to put together $1.5 million, and launched Calm, the meditation app.

It didn’t take long for the Calm app to become popular Credit: Calm App

Lesson 4: Be Clear About How You Are Going To Monetize

From the outset, Tew was very clear about what his value proposition was going to be, and how he was going to monetise his app. To this day, the app’s flagship feature– a 10 minute guided meditation– remains free. Calm makes money by selling premium access to things like ‘Sleep Stories’ (which are basically bedtime stories for adults), and masterclasses on wellness topics.

Calm, Today

Calm’s annual revenue growth is almost a perfect ‘hockey stick

Today, Calm is valued at more than $1 billion and counts the likes of TPG and Ashton Kutcher amongst its investors. The app is locked in a two way battle for domination with competitor Headspace, and was named Apple’s App of the Year in 2017. According to App Annie, an app market data firm, Calm is the top grossing health and fitness app and 20th overall on iOS, while Headspace, its main competitor, is the seventh-highest grossing health and fitness app and 103rd overall on iOS. With more than 40 million downloads and more than 1 million paying customers, Calm’s success has been nothing short of extraordinary.

And behind much of this success is one man: Alex Tew (and his life lessons).


Data May Be The New Oil, But Don’t Be A Rockefeller

Is there a right way to use your customers data?

In a world where data was touted as the ‘new oil’, it was only a matter of time before the debate between privacy and data sharing reached a new crescendo. Starting with Cambridge Analytica, scandal after scandal has kept alive the ever-evolving debate around how our personal data is collected and used.

In short… don’t be Dogbert Credit: Scott Adams/Dilbert

To begin with, sharing data does have its merits. For instance:

  • Medical researchers need access to confidential patient data to use in their studies of diseases to identify cures.
  • Retail chains need consumer data to identify markets that can support new stores while meeting demand.
  • Municipalities need to share data to improve transit systems and public safety.
  • Makers of intelligent connected cars need to enable vehicle data exchange and the monetization of vehicle data while protecting data privacy.

However, when companies and app developers start using this vast pool of data at their disposal to create new revenue streams by essentially commoditizing the user, there arises a question about the ethics of such practices. For instance, The Verge has revealed that while struggling to generate revenues post-IPO, Facebook considered selling access to user data in order to make money. Last year, Buzzfeed News revealed that out of nearly 160,000 free Android apps available on the Google Play Store, nearly 55% tried to extract and share the users location with third parties, while 30% accessed the device’s contact list.

In light of all this, it is only natural for users to start worrying about the privacy of their data, prompting governments to crack down hard on firms and developers who misuse personal data. But, as developers, how do we ensure that the data we collect is used for the common good, and not for any nefarious purposes (even by accident)? Where do we draw the line when it comes to data collection practices?

Here is a list of best practices (and common sense) which we advise our clients to follow

Have a privacy policy

Before you try to collect any data at all, it is important to think really hard about why you want to collect customer data, how you want to use it, and whether or not you will be sharing this data with external parties. Once these basics have been figured out, build upon them to formulate a data collection and privacy policy for your company, product, or app. Use simple, clear language (because nobody understands legalese), but run it past your lawyer to make sure that everything is okay. Finally, make the policy available and easily accessible on your website and app.

Be transparent

While the law may shape how you disclose your policies and handle your data, being transparent with your users about how their data is collected, used, and shared is a very good idea. After all, being transparent builds trust. Providing users with the power to control the data they share with you is also a giant leap forward. For instance, if you’re developing an app, consider providing users the ability to view, limit, or delete the data they have shared with you. This will ensure that whatever data you have with you, has been collected entirely with the consent of your users.

Designing self-service pages where users can control their data can be a huge step forward for user privacy and consensual collection. Users can understand the data they’ve explicitly provided, the data you’ve gathered in the background based on their usage, and the ongoing ways that data is currently entering your systems. This encourages users to take an active and considered approach to their own privacy and allows users to refuse specific types of collection with an understanding of how that may affect their access.

When given a choice between collecting and correlating data in the background and asking for it explicitly from users, it is usually best to tend towards the latter. While your privacy policy may outline various ways that you may gather data, asking directly will minimize surprises and help build trust. Users may be willing to provide more information when they feel like they control the interaction rather than when it is collected by monitoring behavior, which can feel intrusive.

If you’re domiciled in a locality where GDPR applies, then it goes without saying that almost all of the above are requirements that you must comply with. GDPR is essentially a legal framework which governs how firms can collect and handle user data, while providing greater protection and rights to individuals. The costs of non-compliance with GDPR can be quite high. Smaller offences could result in fines of up to EUR 10 million or two per cent of a firm’s global turnover (whichever is greater). Those with more serious consequences can have fines of up to EUR 20 million or four per cent of a firm’s global turnover (whichever is greater). For more information, see what The Guardian has to say.

Build strong safeguards

If you are collecting user data, a data breach can be your worst nightmare. Not only would it be a public-relations disaster, but in a worst-case scenario, it could spell the end of your company or startup. Data breaches lead to people’s identities being stolen, credit cards being opened in their name without them knowing it, and even fraudulent tax returns being filed. If you’re going to collect all this personal data, it’s your responsibility to safeguard the data you collect.

To that end, we recommend that you:

  • Back up your data in case your systems crash
  • Ensure there is no personally identifiable information within your database (make sure it’s all encrypted or anonymized)
  • Have malware, antivirus software, and firewalls that protect from data breaches (and make sure it’s all up to date)
  • Have an emergency plan in the event of a data breach

Minimise permissions

When you ask users permission to access certain data or services on their phones, ensure that you are only asking for permissions that are appropriate, and not excessively intrusive. For example, if your app is a simple tic tac toe game, it doesn’t make sense to ask the user for permission to access the camera on their device.

Don’t use code you don’t understand

Developers usually work with a lot of open-source software when building apps, and it is a very common (and good) practice to rely on other people’s code snippets, be it in the form of frameworks or libraries, where relevant. Platforms such as GitHub are a treasure trove of top-notch code snippets, which can often cut development time by a significant amount. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.

What are your thoughts on the data privacy vs. data sharing debate? Let us know in the comments below!

Cover image credits: Unsplash


Lessons for startups from Zoom

Zoom, the video conferencing startup which managed to beat Cisco’s WebEx at its own game, recently went public. Leaving the IPO aside, there was a lot of media attention on Zoom’s history as a company, since it very much broke the stereotype of the ‘hot Silicon Valley startup’.

Before Zoom arrived on the scene, many thought that the problem of video conferencing had been solved thanks to Cisco’s WebEx and Skype. But that’s not what Eric Yuan thought. A founding engineer on the WebEx team, Eric was passionate about building a video conferencing solution that just worked. He tried to implement his ideas at WebEx, but his bosses didn’t want to listen, and Eric left WebEx to found Zoom.

Eric Yuan, founder of Zoom / Source: Thrive Global

Having looked at Zoom’s growth from afar, here’s what we think all other startups can learn from Zoom

Be focused on the product, maniacally

This story about how focused Zoom is on improving its product comes directly from Sequoia Capital, one of Zoom’s investors. But before they became an investor, Sequoia was a paying customer of Zoom.

“When Sequoia first reached out to Eric in 2014, he told us he admired our work but wasn’t looking for funding. Then he asked for an intro to our IT department, to see if they’d be interested in using Zoom. He cared more about our business than he did about our money — because he was, as he is today, singularly focused on his mission of making people happy.”

-Carl Eschenbach & Pat Grady, Sequoia Capital

Many early-stage startups suffer from a tendency to focus on securing funding, instead of focusing on their product and acquiring paying customers. But Zoom’s approach of focusing on acquiring paying customers, which indirectly gave them more leverage when negotiating with investors later.

To exhibit how focused Zoom is on making its product good, consider this. In a recent feature on Zoom, Forbes columnist Alex Conrad wrote that Zoom could operate well even on a connection with 40% packet loss, which is a boon for those on spotty or slow connections.

Zoom’s platform / Source: Company S-1

Build sustainable revenue streams

In Silicon Valley, there is a tendency to chase revenue growth which is usually fuelled by deep discounts and/or by running at a loss. A ready example can be found in the meal delivery startup sector, where profitability remains elusive yet discounts, plentiful. Essentially, most startups in the sector are hemorrhaging money to make a little bit of money or no money at all. Worse yet, some will never see a cent in profits for a very, very long time. Not so with Zoom.

Consider the following, taken from the second page of Zoom’s S-1 document:

“Our revenue was $60.8 million, $151.5 million and $330.5 million for the fiscal years ended January 31, 2017, 2018 and 2019, respectively, representing annual revenue growth of 149% and 118% in fiscal 2018 and fiscal 2019, respectively.”

But the next section makes things even more interesting:

“We had a net loss of $0.0 million and $3.8 million for the fiscal years ended January 31, 2017, and 2018, respectively, and net income of $7.6 million for the fiscal year ended January 31, 2019.”

Simply put, Zoom was already a profitable company when it sought to list its shares, a rare achievement in the startup world. For comparison, look at the finances of some other startups which went public in recent times:

  • Pinterest, who filed on March 22nd, the same day as Zoom, made $755M in revenue in the fiscal year 2018 but a net loss of $63M.
  • PagerDuty, who filed on March 16th, made $79.6M revenue in the fiscal year 2018, but a net loss of $38.1M.
  • Lyft, who filed on March 1st, made $2.2B revenue in the fiscal year 2019, but a net loss of $911.3M.

In the technology world, running at a loss in order to get a shot at an IPO is widely considered a necessary evil. But Zoom was comfortably in the black, which allowed the company to list at a valuation of USD 8.98 billion.

Zoom’s financials remain healthy / Source: Forbes

Your users can be your best evangelists

Zoom credits its growth to its bottom-up user generation cycle, which conceptually, shares a few similarities with Dropbox’s famous referral system. With Zoom, users can sign up and invite others to a meeting (for free) and when they realize how easy-to-use and great the product is, they sign up too and then pay for more features.

Zoom’s S-1 states that amongst others, the company had 344 customers who generated more than $100K in annual revenue, up 141% YoY. This customer segment accounted for 30% of Zoom’s revenues in FY’19. 55% of those 344 customers started with at least one free host prior to subscribing. As more and more customers invite people to meetings held on Zoom, those numbers are only going to rise. Consider this quote from a Sequoia spokesperson:

“We had been watching the video conferencing space for many years because we were convinced that it was a huge market primed for innovation. But we couldn’t find a product that customers loved to use. That changed when our portfolio companies started raving to us about Zoom.”

Execution matters

When Eric Yuan decided to build Zoom, the problem of video conferencing was, for all intents and purposes, considered to be solved. There were many incumbents, ranging from WebEx to Skype and Google Hangouts. But they were full of problems. Some were built for an age where video conferencing was done in front of a computer, some didn’t have features such as file sharing from mobile, etc. In trying to build a better video conferencing product that truly lived off the cloud, and scaled simply and scaled well, Zoom did not try to reinvent the wheel. Instead, they just set out to make a motorized car while the rest of the world was content to ride on horse-drawn carriages. Unsurprisingly, Zoom is a company favoured by Social Capital CEO Chamath Palihapitiya, who ranks it on the same level as Slack, another successful tech startup (of which Palihapitiya is an investor).

If you’re building a startup yourself, we highly recommend that you keep an eye on Eric and his team. In the meantime, if you are a user of Zoom, what was your experience with the product like? Do you think Zoom will become the next Slack? Let us know in the comments!



Bridging Cultural Differences: Our Thoughts

Being in the software development business, our clients come from the world over. Naturally, there are cultural differences which may get in the way. At Calcey, we have a few tricks up our sleeves to help bridge these differences and help us deliver great work.

Every country has a culture that is unique. Sri Lanka, where we are based, has traditionally been hierarchical, collectivistic, and driven by a need to achieve consensus. What this means is that generally:

  • Subordinates expect to be told what to do and the ideal boss is a benevolent autocrat.
  • Everyone takes responsibility for fellow members of their group.
  • People strive for consensus, and they value equality, solidarity and quality in their working lives. Conflicts tend to be resolved by compromise and negotiation.

Geert Hofstede also agrees with us.

Lesson 1: Don’t throw the baby out with the bathwater

Sri Lanka’s collectivist culture brings with it a few positives, which serve us well as a global software company. The hierarchical elements though, aren’t of much use. Calcey’s internal culture is consciously and painstakingly built around values such as ‘Straight Talk’ and ‘Challenging Convention’. Obviously, there can be clashes.

New recruits often say that they find the Calcey culture a breath of fresh air compared to what they experienced while at University

Once new recruits come to Calcey, we try to encourage them to break free of the traditional  notion that being straightforward is undesirable, and challenging seniority is a no-go. At the same time, positive aspects such as collectivism and the high camaraderie which recruits bring with them need to be encouraged. In an industry such as software, those elements tend to be very valuable.

Lesson 2: Leverage the similarities

The tech sector in general, is somewhat counter-culture, no matter where you are in the world. Because of this, tech employees the world over have certain similarities between them. Not only do they speak the same languages in terms of code, they even chuckle at the same memes. This commonality helps us build a good rapport with foreign tech teams, whenever we encounter them.

Capitalising on similarities helps people get along better

Lesson 3: Achieve a personality fit between the client and the project team

Since our clients will end up spending most of their time dealing with the project team, it is crucial that there is a good personality match between the two parties. Even more crucial is getting a good personality match between the client and the project manager, who will be the main point of contact.

Starting from the pre-sales stage, we try to gauge the personality traits of the client. Being a boutique firm, there is a lot of personal involvement in the sales process, and this gives us enough time and space to understand the client very well. This knowledge then helps us to put together a project team which usually ends up getting along well with the client.

It’s important that the project team is a good fit with the client

Lesson 4: Hire well and hire right

This is a no-brainer really. When hiring, we look for people who display a good level of empathy and are open to embracing new perspectives. Graduating at the top of your class is not everything after all.

We also have quite a few experienced hands in-house, who bring with them loads of international experience. They’re always around to help smoothen things.

And that’s it really. Though overcoming cultural barriers is not complicated as it appears to be, failing to understand the impact of culture can be disastrous for any business. Our methods though simple, are powerful. Most importantly, they work.