But how can you tell one potential partner from another? Here are some key questions to ask during the selection process:

How do you know you can trust them?

Nothing matters more than this. If you have any doubts whatsoever, walk away. A good first step towards finding a reliable partner is to seek recommendations, demand references, and ask their customers questions like: What are they like to work with? Have they delivered the right outcomes for you? How have they dealt with problems? How collaborative are they?

How good are their technical skills really?

Every potential partner will tell you that they have amazing technical skills. Really, really talented people. The best in the industry. But how do you know how good they are in reality? It’s important to talk to the technical leadership to see if they genuinely understand your technology and what good looks like. It can also be worth interviewing the people who’d be working in your team. 

Do they understand how to build secure systems?

Today, all systems need to be secure – and by using tooling as part of the build process, teams can ensure security is embedded throughout the development process. So, are all the people in your partner’s team security aware? And are they given appropriate training on the subject?

Are they focused on delivering value?

Too many near-shore teams will prioritise billable hours over delivering genuine value to their clients. However, for both you and your potential partner, value – rather than actual cost – should be top of mind. In particular, going with the cheapest option might not always result in the best value for your organisation. If your partner doesn’t have the right technical or collaborative skills, for example, poor outputs and delays could end up costing you dear in the long-run.

Is there a commercial awareness right across the business?

The advent of the public cloud has introduced a completely novel dimension to designing new systems. Architectures must be cost-effective in their use of cloud services, which means those designing them must have a current knowledge not only of the services available, but also the pricing implications which may depend on usage patterns.

Are they in a suitable near-shore location?

Here, you’ll need to consider issues like cultural alignment and time zone differences. It’s really hard to make agile development processes work well if your teams’ working days barely overlap or your potential partner doesn’t have an ethos of close collaboration.

Do they have good English language skills that run deep in the business?

Check that everyone speaks good enough English to enable peer-to-peer contact between your team and theirs. If all communication has to go through a project manager, as they’re the only one who speaks your language, misunderstandings and delays will become inevitable.

Do their people collaborate easily?

Having a naturally collaborative culture will make communication at all levels much more straightforward. Everyone needs to be able to communicate easily and transparently so that issues and opportunities can be discussed openly.

The best way to find answers to all the questions above, and reassure yourself that you’re selecting the right partner, is to spend time with them. Find out if they’re happy for you to visit their offices as often as you wish. Insist on meeting the people you’ll be working with – and not just the senior management and sales team – and ask them some tough questions. The more time you spend doing this, the more you’ll find out what the business is really like to work with.

Finally, once you’ve selected your potential partner, or drawn up a shortlist, it’s often a good idea to put them to the test before committing to a contract. For example, you could give them a problem to solve – and even if it’s not a live issue, the way they go about finding a solution can be very revealing as to the way they operate.

Alternatively, you could engage them on a small, live project and measure them on how they handle it. This is a very low-risk way of assessing whether the potential partner is likely to be a good fit for your own organisation. Here at Damilah, we’d be more than happy to discuss any of the above questions with you and explain our ‘partner-shoring’ model to you – where our near-shore team will collaborate seamlessly with you to deliver high levels of shared value.

To find out more, get in touch now to discuss our range of services.

Here’s how you can make it work:

The scale-up challenge

Often private equity-backed owners will be looking to invest in the product to significantly grow revenue. Typically, this may involve transforming a monolithic on-premise software product to a modern SaaS offering, or extending the product into other markets.

Whatever the plan may be, it’s likely to create a need to rapidly expand the engineering team. This could be in terms of head count, and potentially also to bring in new expertise if the scale-up involves a significant technology shift and the necessary know-how doesn’t already exist within the business.

Going outside the business to solve the problem

A highly effective way to solve this problem is to bring in expertise from outside, as hiring and building a team internally can be time-consuming, costly and risky.

That’s why turning to a near-shore partner, with flexible teams and talented people who have done this many times before, can reap big rewards. They will be able to offer, for example, experience and understanding of how to use public cloud in a cost-effective way, how to build cloud-native SaaS products, and so on – while maximising the benefits of modern standards and approaches, such as automation, continuous testing and rapid delivery cycles. This can be a very cost-effective way of putting an outstanding final product into users’ hands as quickly as possible.

An added advantage can be the way in which you can easily scale the development team up or down. For example, a private investor may often begin to reduce their levels of investment after year two or three as they look to grow their bottom line prior to exiting after five years or so. In turn, that may require a scaling back of the engineering team, which is harder to do if it involves laying off internal employees.

Setting up autonomous teams

None of this is likely to work well unless you create autonomous teams that remove as many dependencies as possible – as dependencies are the biggest productivity killer when it comes to software development. If completing a task depends on input from another team or individual, working at pace frequently becomes impossible – which is exactly the opposite of what a major scale-up needs.

Instead, an autonomous team will have all the skills and experience necessary to forge ahead successfully and at pace. They will be able to handle everything from talking to end users about their needs, and creating a roadmap and product strategy, right through to production and deployment, with all the necessary DevOps, engineering, testing, and product people in between that are required to get the job done.

The Spotify model

In my opinion, autonomous teams are the only way to scale rapidly – and using the Spotify model is an example of a good way to build and maintain such teams.

At the top, there is a tribe leader, who may be responsible for multiple teams, each one containing all the skills necessary to complete a project. The tribe leader is empowered to make decisions and move people around their teams as necessary.

Then, across those teams, there are special-interest groups called guilds. These are collections of people who have the same areas of expertise, and they are used for sharing knowledge and advice across teams. Each guild will have a leader, who is a specialist in their field, but may not be from the management team.

And there are also chapters, which are a way of managing and mentoring individuals, without the need for multiple layers of line management.

Overall, this model is an effective way of running large teams, because the CTO can focus on supporting the tribe leaders and then only managing by exception – in other words, not having to focus too much on details unless there is a specific problem, in which case they can go in deep to help find a solution.

Leveraging the benefits of near-shoring

The crucial factor to bear in mind throughout all of the above is that it is not necessary for an team to be physically co-located. As long as its members have the necessary autonomy and the ability to collaborate seamlessly, they can be anywhere. This allows you to leverage the cost and flexibility advantages of partnering closely with a near-shore company – or ‘partner-shoring’, as we like to call it.

Over the years, I’ve helped many businesses to rapidly scale up and significantly increase their value by deploying these methodologies.

To find out more about how we at Damilah can help you to do the same, get in touch now to discuss our range of services.

Iain Bishop, founder and CEO, Damilah

Or maybe you’ve engaged a far-shore ‘partner’ in India who always says everything is fine and on time, but frequently delivers late and with sub-standard quality.

These are, of course, generalisations – but they have happened too frequently to me, and others I know, to be outliers.

Either situation is extremely frustrating, potentially costly, and will fail to produce the kind of results that you and your organisation require. That’s why, at Damilah, we have developed the ‘partner-shoring’ model – a different way of approaching near-shoring.

What do we mean by partner-shoring?

Using this model, the client and supplier work seamlessly together towards common goals. Some people in the team may be from the client side, some from the supplier – but to an outsider it should be virtually impossible to tell which is which. That’s because they collaborate as genuine partners to build the best possible product within the constraints set by the business.

The teams are also fully autonomous, containing all the skills necessary to deliver the products end users are looking for. This maximises productivity by removing as many dependencies as possible, which often tend to slow progress.

How does partner-shoring work in practice?

Here’s a good example of the collaborative culture we foster at Damilah. With one of our clients, the autonomous team is led by a triumvirate comprising a product manager, an architect and a delivery manager. One of those roles is provided by the customer, the other two by us. But they are all equal in status – and we call them the Three Amigos, as they work so closely together on projects.

The product manager aims to create the ideal product to meet customers’ needs. The architect works out how to do this, the challenges involved, and how long it will take. And the delivery manager looks after putting the plan together and ensuring everything is delivered on time and of high quality.

Above all, the Three Amigos are mature and experienced people, equals who are constantly working together on discovery, understanding what needs to be built, and prioritising work based on business needs, difficulty and time requirements – without the traditional ‘them and us’ client and supplier relationship.

Why does it require a near-shore team, rather than a far-shore team?

We believe this gives our clients the best of both worlds.

In the first instance, you can leverage the cost benefits of working with an off-shore team. But, at the same time, this kind of partnership is hard to achieve when the teams are far apart in geography, time zone and culture. On the other hand, if the people involved can spend time face to face, working together, planning, resolving challenges – and even socialising – then positive working relationships will form and truly enable close collaboration and velocity.

If your European-based team has to travel for an entire day to reach a remote part of the world, then suffer from jet lag, they will probably be reluctant to visit their partners very often. And that’s not to mention the difficulty of getting expensive travel costs approved. As a result, the kind of closeness and effective teamwork that comes from frequent contact is unlikely to arise. On the other hand, if the partner is just a few hours away, with a one-hour time gap, it can make all the difference.

Furthermore, although there may be some minor cultural differences between teams in the UK and, say, Eastern Europe, these are likely to be far less pronounced than between the UK and South or East Asia.

What are the main benefits of partner-shoring?

Working with a partner whose team feels like an extension of your own, and is fully aligned with your own business requirements and goals, allows you to successfully leverage the advantages of near-shoring with a company that is already established in the overseas market.

That means your partner can ensure people are rewarded appropriately while you also benefit from their deep market knowledge and understanding when it comes to aspects such as local regulation and cultural differences. In other words, you can build confidence in the process, the people and the location with minimal risks.

There are also the benefits of reduced churn that tend to come from a well-run near-shoring operation. In many Indian off-shore firms, for example, it’s common to see annual employee turnover at rates as high as 25% or 30% – whereas our Damilah team in North Macedonia has a rate of around 2% on average.

And, last but not least, there are the advantages of transparency. If a development team works as a black box – where the client knows very little about what’s going on until the product is delivered – you’ll frequently hear that everything is going well… until the day of delivery. And then you might hear that there’s been a problem – and delivery will be delayed for a month or three.

Such issues are common among teams in geographies like India, where culturally people are reluctant to deliver bad news. On the other hand, European teams tend towards more transparent working practices. This makes it easier to be aware of problems as they arise, allowing you to find a solution – such as prioritising certain features or narrowing the scope – while still hitting the delivery date, rather than being trapped in a last-minute situation where you have no way out.

If you’d like to find out more about the ways partner-shoring could benefit your business, and how Damilah can help, get in touch now to discuss our range of services.

Iain Bishop, founder and CEO, Damilah