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

Microservices have been a buzzword in tech blogs for almost a decade now. Introduced by James Lewis and Martin Fowler as a logical evolution of Service-Oriented architecture, microservices offer IT organizations the opportunity to stay relevant and evolve their products constantly in an ever-changing software market. While many successful organizations still rely on legacy solutions built using monolithic architectures, the advantages offered by microservices far surpass the associated risks.

Moving to microservices can bring many positive changes to IT organizations. Microservices allow scalability, flexibility, resilience, improved development speed, and maintainability. These benefits give IT organizations an edge over their competition, making it essential to consider a move towards microservices:

Scalability: Microservices can be scaled independently, allowing organizations to handle changes in demand without having to scale the entire application.

Flexibility: With microservices, organizations can make changes to individual services without impacting the entire application. This enables faster iteration and deployment.

Resilience: If one service fails, it does not affect the entire application. Other services can continue to function, providing better availability and resiliency.

Improved development speed: With smaller, independent services, development teams can work on separate services concurrently, increasing the development speed and reducing time-to-market.

Maintainability: As services are separated and decoupled, it is easier to maintain and update them. This reduces the risk of introducing bugs or errors when making changes.

However, migrating from legacy monolithic solution to microservices is not an easy task. Failed attempts to migrate or to do microservices right on a green field solution can put many IT organizations at risk of losing their market advantage. Careful planning and analysis are required to avoid costly mistakes.

The migration process requires a thorough analysis of the existing monolithic solution, including identifying the different components of the platform, their dependencies, and data flows. Migration impact on existing workflows and business processes should also be considered. The outcome of this analysis will fit into the strategic plan for migration, including breaking down the monolith into smaller services and determining appropriate boundaries between them.

To minimize disruption to the existing platform, a phased migration approach is recommended. This involves migrating one component at a time, starting with the least critical components and gradually moving towards the more critical ones. Ensuring quality along the way by setting the right testing practices is also important.

The execution of the strategic plan may impact the organization’s structure as well, making it essential to have the right people in the right place. Experienced consultants can make a real difference between success and failure in this process. At Damilah we have the experteese in the process of migrating from monolithic solutions to cloud-native SAAS solutions using microservices architectures.

In conclusion, while microservices are not the silver bullet, they offer numerous benefits that can make a significant impact on an organization’s success. Careful planning and execution with the help of experienced consultants can help organizations migrate from legacy monolithic solutions to microservices architectures with minimal disruption and maximum success.