What would your top 5 learning points be for startups related to delivery services pitfalls? What are some of the recent cases you have seen in your practice?
By the time we meet start-ups they usually have both a good idea and a first-generation platform. They have learned much about their customers and are considering their second-generation platform. This will need to scale and perhaps deal with a host of customisations or new features for the customers they have in their sales pipeline. As such, they face the following challenges:
The trap most startups fall into is to try to keep hold of all the core software (which is totally understandable) and shave off bits around the edge of the platform to outsource suppliers. To do so ties up the core team in tightly specifying small, low-value work packages that they have to integrate into the core project. It’s a poor use of time, and you get little value from your supplier.
My first learning point is to find a supplier you think you can trust and let them inside your thinking and plans. You don’t give them core IP, but you have to let them see your direction of travel so that they can contribute directly to it – they may even have better ideas on how to deliver some elements.
So, second, work through your roadmap highlighting the areas where you think they could contribute. Perhaps work backwards from a notional press release which describes the go-live and the great partnership you’ve built to get there. Now, what do you need to do to make that a reality?
Third, share a common way of working; that means everyone delivers to the same processes, coding standards, CICD, peer review, test automation, and design patterns. It also means making your supplier a partner in your quarterly planning, your Sprint Reviews, and company updates (providing they are not financially sensitive). Your goal is to make your supplier an extension of your capability helping you scale quickly without changing your culture or way of working.
Fourth, remember that you don’t need to solve every problem yourself – it’s OK to buy in expertise if it will save you time, rework or technical debt. For example, if you’ve built your platform on AWS but now have an Azure customer, buy in some Azure expertise, even if only for a few months, to accelerate your learning.
Finally, (and my fifth learning point) is to look ahead to enterprise customer installations. Many start-ups invest heavily in building their knock-out product and chasing the big customer. What happens when you land that customer and they need to integrate your product with their corporate ecosystem? One really simple way to use a supplier is to provide separation from your internal team: they see your software as an outsider might. Examples include building an app based on your APIs, a developer portal, or a reference implementation.
What was the most challenging assignment you engaged in while in Estafet and how did you approach its solution?
A customer thought they had defined a solution well – there was a massive spec and a clear expectation that it should be delivered with no need for further communication. Except that (almost) all such written specs contain ambiguity. Our customer had conflicting ideas as to the technical solution and only recognised that delivery was not what they needed months after it had been built. We solved this by bringing the customer and development team closer together, explaining the technical choices available to the customers’ enterprise architecture team, and the business goals to the development team. We targeted test automation to areas of maximum uncertainty and where the bulk of the code and configuration lay. We brought all sides to design and review meetings to establish a common understanding, using the spec as a guide to what was needed rather than the contractual commitment. The result was a better (and simpler) system than had been specified: one that was easier to maintain (and regression test), and more flexible to extend and meet the growing needs of the customer.
When would you advise a start-up to outsource tech-related tasks and when should they keep such tasks in-house?
As said, keep core IP (e.g. your USP) in-house; it’s what differentiates you from the competition and drives your staff. Think about outsourcing for:
- Customisations (always through new components/adapters, never through different versions of your software or you’ll hit spiralling maintenance costs);
- Testing (everyone thinks of security/penetration testing, but also think about behavioural testing where you can agree on scenarios with your Product Owner, and then leave the implementation to your supplier)
- Removing barriers to entry for new customers (e.g. by building a developer portal, reference implementation, integrations with customers’ systems)
- New technical challenges where you don’t have in-house expertise (e.g. moving to multi-cloud, adopting an API gateway, integrating with new security models)
- Scaling delivery. It’s great to build everything in-house; however, growing organically is slow and expensive, whilst your demand for it is often short-term. Add whole new teams or split your existing ones and backfill with nearshore to cut costs without slowing you down.
In your view, how is Estafet different from other nearshore delivery partners?
Start-ups adopt nearshore to scale delivery more cheaply. However, to do so successfully means finding a partner who:
- Works the way you do
- Knows the tech you want to work in
- Is small enough for you to really matter to them
- Is focused on achieving your business goals
I think size is an important part of that: big companies are much more focussed on selling you lots of heads because their profit comes through economies of scale. But it’s also culture; we’re good at building trust because we see things in terms of the business outcomes you are trying to achieve, looking ahead to how we can release quickly and safely, sharing insights and knowledge we have gained, and bringing in best practices from previous projects to help you go faster.
Our management sees itself as serving the customer and consultants so that they can do their jobs better. We also recognise that our sales come from recommendations rather than pitches, which means we need to understand your roadmap and produce good, pragmatic software solutions to achieve it.