Episode 4: EntityShift

Hi, and welcome to the OntargIT podcast — real stories from the world of Microsoft technologies and global partnerships, told without the gloss. I’m Volodymyr Lysenko from the OntargIT team. Today we’ll talk about how partnership actually works between two technology teams. My guest is Jason Newbatt, Technical Director at EntityShift, a company helping organizations transform through technology. We’ll cover how our collaboration began, what makes multi-vendor teamwork succeed in complex enterprise environments, and where tools like Power Platform and Dynamics 365 are heading next. Jason, great to have you with us. Let’s get started.

Thanks

Could you briefly introduce yourself and your role, and tell us a bit about EntityShift?

I’m Jason Newbatt, Technical Director for EntityShift. Part of my role is looking after everything technical — the ALM, the development, and the more technically complex elements of solution delivery within Dynamics 365. I work alongside colleagues who specialize in the operational and functional sides of things — resourcing, project management, and so on — while my domain is anything that touches development, ALM, and the more technical, coding-related elements.

EntityShift is a small, boutique, UK-based finance and operations dedicated partner. We call ourselves an enablement partner rather than a systems implementer, because our focus is on making sure customers can own their own implementation. We find that the most successful implementations happen when the customer really leans into the project and takes it on as their own — to the point where responsibility shifts increasingly to the customer’s side. So we focus on tools, relationships, and capabilities that speed up that journey and help the customer own their destiny sooner.

Nice to meet you, Jason. Thanks for sharing that. Building on what you just touched on: what are the key technology areas your team specializes in when driving business transformation?

From a transformation perspective, it’s always important to focus on the actual value of what we’re doing for the customer — the outputs, the benefits, and the destination they’re trying to reach — and then apply that to the technology. We’re purely focused on finance and operations, so we’re engaged principally where people have already chosen that technology and are fully invested in getting it right.

But ERP, at enterprise scale, requires capabilities that span end to end — not just core finance, but projects, manufacturing, customer engagement, quality management, and more. The process often starts outside the ERP system, even though it will always end there. So we’re committed to having the right partnerships in place to address a proper end-to-end transformation. Your ERP system might represent 70–80% of your estate, but you still need to address that other 30%, because a problem created outside the system only gets multiplied once it reaches the ERP — and the right solution to that problem might be process change rather than technology.

That’s a great point, thank you. Now, something I think will be really interesting to hear from your perspective: how did the collaboration between EntityShift and OntargIT begin, within our shared client project?

One thing that shouldn’t be underestimated is the value of deep technical expertise. Any prime contractor — or whoever holds ultimate contractual responsibility for the deliverable — needs to be able to rely on that expertise to solve problems and take away friction, not add to it.

One of the first things we noticed working with Volodymyr specifically was the depth of expertise he brought to our project — any technical challenge we tackled together was solved within 24 to 48 hours. On top of that, we had plenty of challenges along the way: shifting timelines, deadlines brought right up to the edge, and the need to get things done quickly, which meant late hours and late evenings solving problems.

Knowing that OntargIT provided us with that capability — and that dedication to just get the job done — was essential. It’s meant that this has been an absolutely fantastic partnership from the offset, and we’ve been very pleased to work with you on our mutual project.

From your point of view, what makes multi-vendor collaboration successful in complex enterprise environments?

Enterprise organizations understand this well: an enterprise-scale problem isn’t necessarily incredibly complex, but it usually spans many different areas. No single individual can do everything end to end — it’s simply not possible for one person to know everything a platform like Dynamics can do across every module and every area. You need deep specialism in each area.
Unless an organization is willing to keep 25 people permanently on staff, each with their own area of expertise, most organizations — especially smaller, more agile ones — need good partnerships that let them stay true to their own vision and expertise while bringing in others who provide that depth. It also helps with scale: work often comes in waves, and predicting spiky workloads from an expertise perspective is very difficult for a small or medium-sized partner to manage alone. Keeping partnerships in place spreads that risk and lets everyone stay focused.

How do you ensure alignment between different teams and maintain a shared vision for the client’s goals?

Transparency and talking. A picture paints a thousand words — getting people on a call together, understanding from a single source what needs to happen, and having collaborative calls so everyone can see the journey end to end, is essential. The question is how to do that efficiently, without having, say, a sales specialist sitting in on a manufacturing discussion just because no one has decided whether there’s enough overlap to justify their involvement. Everyone should have the bird’s-eye view, but not everyone needs to sit in on every workshop — that would just slow things down.

We had weekly cadences for catch-ups, and daily check-ins to stay on top of what everyone was working on and what challenges each area was facing. Being able to openly discuss where we stood meant we could solve problems from different angles. On our recent project, for example, we had some manual tasks — confirming purchase orders was one — that we hadn’t automated. There were technical options that could have solved that much faster, and we wouldn’t have arrived at those conclusions if we hadn’t discussed those areas together and been involved in the issues each side was experiencing.

That’s a great point, thank you. Following on from that: in your experience, what value does this kind of cross-company collaboration bring to the end client?

The end client mainly cares that their overall project is successful and delivered. They may not be involved in every intricacy, but they do experience turbulence, delays, and nervousness about outcomes if they’re not given the right level of assurance. In other words, they experience the symptoms of a bad set of relationships. Having concrete coverage across every area — the kind a strong partnership brings — minimizes or eliminates those symptoms, to the point where the client is blissfully unaware of the internal partnerships delivering the solution.

If they’re not aware of that, it’s almost a mark of success — they haven’t had to inspect the inner workings of the delivery machine to figure out what isn’t working. They just experience a successful, seamless outcome, which is exactly what we want.

That makes a lot of sense, thank you. Next briefly, which technologies or methodologies have been particularly impactful in delivering business outcomes for this project?

This project has gone through a number of stops and starts, depending on various factors — changes of direction, increases in scope, decisions about which divisions would go live first or second, and so on. The most impactful thing was the ability to change and adapt to those circumstances. I wouldn’t call it agile exactly, but having that agility — being able to throw away three weeks of effort to redesign something rather than let it break the next two or three months of work — was essential.

We haven’t had a rigid methodology where it’s ‘our way or the highway.’ We’ve taken a more adaptive approach, and with OntargIT we’ve been able to flex that approach whenever needed, with no negative impact — which has been great.

That’s totally right — looking back, it really was an interesting experience, especially with all those late hours. It’s hard to point to just one specific technology or methodology.

Indeed. It’s been a winding journey of different approaches, and how we weathered those has honestly been the fun part.

You mentioned earlier that your company is mostly focused on Dynamics 365 Finance and Operations — but I’d love to get your insights on how you see Microsoft Power Platform and Dynamics 365 evolving as tools for enterprise-scale transformation in the coming years.

Even though we’re principally focused on finance and operations, the team is well versed in the broader capabilities of the Power Platform. We wouldn’t jump straight into a customer service implementation ourselves — that’s not our forte — but we understand how that area overlaps with the ERP side of a project.

First, get your ducks in a row and evaluate what you’re actually asking for. If you don’t know what you’re asking for, it’s worth running a consultative exercise first, to make sure you’re going to market with the right questions.

For organizations building their own solutions or in-house teams, it’s important to know which partners you trust with each area of delivery, and to have clear asks for the depth of specialism you need. So, know your shopping list if you’re going down the multi-partner route, and pick people who can bring that depth in each area.

If instead you’d rather have one larger, GSI-style organization take full responsibility for delivery and manage all the multi-partner relationships itself, that’s a valid route too — but then the question of capability just shifts to that next SI, and your customer becomes the partner in this case rather than the end client. Either way, knowing your shopping list is the most important thing, because if you don’t know what you’re in the market for, you can’t properly evaluate what comes back.

Finally, Jason, what advice would you give to enterprise leaders looking to strengthen collaboration across multiple technology partners?

First, get your ducks in a row and evaluate what you’re actually asking for. If you don’t know what you’re asking for, it’s worth running a consultative exercise first, to make sure you’re going to market with the right questions.

For organizations building their own solutions or in-house teams, it’s important to know which partners you trust with each area of delivery, and to have clear asks for the depth of specialism you need. So, know your shopping list if you’re going down the multi-partner route, and pick people who can bring that depth in each area.

If instead you’d rather have one larger, GSI-style organization take full responsibility for delivery and manage all the multi-partner relationships itself, that’s a valid route too — but then the question of capability just shifts to that next SI, and your customer becomes the partner in this case rather than the end client. Either way, knowing your shopping list is the most important thing — because if you don’t know what you’re in the market for, you can’t properly evaluate what comes back.

That’s a really good point, Jason. Thank you. I believe that’s it for today — thank you so much for this insightful conversation. We’re proud to work with EntityShift, and we’re looking forward to everything ahead.

Thank you very much. Thanks for having me. Appreciate it. Lovely speaking with you.

Thanks again, Jason. That’s mutual, likewise as usual. Thanks again for joining us, and wishing you continued success.