Uitdagingen en kansen in sourcing voor een modern IT-landschap

In deze podcast bespreken Hildo van Es, solution architect en medeoprichter van Greatminds, en Marco van Velthoven, deputy CIO bij een grote multinational, de uitdagingen en kansen bij het ontwikkelen van effectieve sourcingstrategieën. Ze leggen uit hoe sourcing een cruciale rol speelt in het succes van IT-projecten en welke overwegingen belangrijk zijn bij het kiezen van technologieën en sourcingmodellen. Daarnaast bespreken ze de impact van COVID-19 op sourcing en hoe bedrijven zich kunnen aanpassen aan de veranderende omstandigheden in de arbeidsmarkt. Tot slot delen ze hun inzichten over het balanceren van lokale en internationale teams en het minimaliseren van risico's zoals vendor lock-ins.

Transcript

[Hildo van Es] (0:14 - 0:47)

Welcome to the Greatminds podcast. I am Hildo van Es, a Solution Architect and co-founder of Greatminds, a knowledge domain for IT architecture where we approach architecture from different perspectives. In our podcast, we delve deeper into various topics we encounter in architecture, including sourcing and sourcing strategies.

Today, I have a guest who knows a lot about this subject, namely Marco van Velthoven. Marco, could you please introduce yourself?

[Marco van Velthoven] (0:47 - 1:42)

Marco van Velthoven, as you mentioned, I have been working in ICT for about 25 years in various roles. Currently, I am the Deputy CIO at a large multinational. Throughout my career, I have experienced all aspects of ICT.

I started as a developer in the Oracle sector and eventually reached my current role. In the meantime, I have seen everything in the ICT spectrum, from functional application architect, program director, portfolio manager, portfolio director, and finally in a role where I oversee the organization.

[Hildo van Es] (1:43 - 2:19)

Great, so you know a lot about sourcing strategies. When starting a project, you need people, and as architects, we must consider this. It's not practical to implement technologies that no one knows about anymore. For example, we haven't programmed in COBOL for years, so it's not advisable to use COBOL for new architecture.

How do you view this?

[Marco van Velthoven] (2:19 - 2:54)

When designing an architecture and defining systems that add value to the organization, it's essential to look at the availability of people in the market. We are in a time of resource scarcity, so you must also consider how easy it is to scale up and attract people. Where are these people located, and what is their level of knowledge?

[Hildo van Es] (2:54 - 3:04)

Yes, and what technologies do you most often encounter when looking for people? Where are these people found?

[Marco van Velthoven] (3:05 - 4:23)

If you look at the current market, much depends on your strategy at the architectural level. For example, you can choose applications like Salesforce, PEGA, etc. This involves looking more at configurators and trying to use as many out-of-the-box solutions as possible. If there are no suitable applications on the market, you end up with custom solutions. Currently, .NET, .CORE, Java, and frontend technologies like React or Angular are leading. For these technologies, it's easier to find people.

For platforms like Salesforce and PEGA, there are many available professionals, both locally and internationally. PEGA, for example, has a large community in India, and Salesforce is widely used by many companies, so many people want to learn it. You also need to consider the costs of these applications in your considerations.

[Hildo van Es] (4:23 - 4:29)

Yes, exactly. How far do you think architects should go in taking this into account?

[Marco van Velthoven] (4:30 - 4:57)

I think very far. If you, as an architect, choose a niche product that only a handful of people know about, you take a huge risk. Do you want to burden the company for which you are designing the architecture with that risk? Then you have to train people, and the costs can rise significantly in a tight market.

[Hildo van Es] (4:57 - 5:04)

Yes, and not to mention vendor lock-ins and such.

[Marco van Velthoven] (5:04 - 5:12)

Yes, you have personal lock-in at that moment if only a handful of people know the technology, and if they are also with a vendor, you have a catch-22.

[Hildo van Es] (5:12 - 5:12)

Yes.

[Marco van Velthoven] (5:12 - 5:14)

Try getting out of that.

[Hildo van Es] (5:14 - 5:14)

Exactly.

[Marco van Velthoven] (5:14 - 5:22)

That becomes difficult. Not impossible, but you are looking at a major transformation project.

[Hildo van Es] (5:22 - 5:38)

Yes, exactly. And that costs extra money and effort. What kind of people do you often look for? Do you think of more specialists or more broadly developed developers?

[Marco van Velthoven] (5:39 - 6:15)

There was a trend in the market where you had a person for every skill: QA, a front-ender, a back-ender, a DevOps person, observability people, security people. You end up with a very large team. From my experience, I believe you need to go back to a more T-shaped team.

[Hildo van Es] (6:15 - 6:18)

To keep your team as small as possible.

[Marco van Velthoven] (6:18 - 6:27)

But you also need to ensure that you have test-driven development in your development process and that it is truly followed.

[Hildo van Es] (6:27 - 6:27)

Yes.

[Marco van Velthoven] (6:27 - 6:30)

But also that you secure the knowledge within a small team.

[Hildo van Es] (6:30 - 6:45)

And you mentioned test-driven development. Do you also look for specific skill combinations? For example, developers who can also test?

[Marco van Velthoven] (6:46 - 7:09)

Yes, developers who can test are useful, as unit tests are usually the responsibility of developers. But you also look at automation and quality assurance people who can develop. So, you turn it around. You have a quality assurance person who can also develop. In the end, you are working together on the same product.

[Hildo van Es] (7:09 - 7:23)

Interesting. So, what types of sourcing do you have at your disposal to fill your IT organization?

[Marco van Velthoven] (7:24 - 7:40)

If you look at the sourcing models commonly used in the market, you have on-site sourcing, where you enter the local market to find people. These can be permanent employees or hires.

[Marco van Velthoven] (7:40 - 8:42)

Then you have co-sourcing, where you usually collaborate locally with a number of vendors, having a mix of your own people and people from a vendor in a team. Then there's outsourcing, where you look at setting up the entire product team outside your organization and taking more control, but still retaining oversight of the development process. Finally, you have managed service, where you handle vendor management, lay down the requirements, but don't get involved in the development process. How they do it, what methodology they use, how they release it, doesn't matter. You choose managed service.

[Hildo van Es] (8:42 - 8:48)

Yes, and there are of course pros and cons. Can you elaborate on that?

[Marco van Velthoven] (8:49 - 9:19)

It depends on what you want to achieve in the company. What maturity your organization has, and there are several factors to consider. Your time-to-market is an important driver. If your time-to-market is essential, it's more convenient to go for more on-site sourcing. You want that close to home.

[Hildo van Es] (9:19 - 9:27)

Because you then have more control over the end product as well.

[Marco van Velthoven] (9:27 - 10:27)

Yes, control and coordination. Small iterations. You need to collaborate. You also need to exchange ideas. In an outsourced or managed service model, this becomes more difficult. Additionally, you need to consider where your expertise is. Is it primarily local or is it readily available in India? So that's another decision criterion. Flexibility. Do you need to grow quickly or not? If you need to grow rapidly with many people, an outsourced model or managed service model can be suitable. If that's not very important and having a small team and wanting to innovate is more critical, I would keep it closer to home. Is what you are doing business differentiating? If what you are making is a real differentiator for your business.

[Hildo van Es] (10:27 - 10:52)

Yes, I see that. When I choose a package or am in a package selection process, I always look at whether it is a strategic solution. Is it a solution for a strategic part of the organization? Often, I don't want to buy that from a package. So, I see that sourcing works similarly.

[Marco van Velthoven] (10:52 - 11:31)

Yes, with sourcing and, ultimately, simply put, costs. What are the costs you want to spend on development? Some companies choose to minimize costs. Then the advantage is to outsource, because the costs are lower there. When you look at India, you must calculate with a factor of 1.3. So, if you need one person in the Netherlands, you need to multiply that by 1.3 in India, but ultimately, it's still cheaper in the end.

[Hildo van Es] (11:33 - 11:57)

Are there certain parts of organizations that are easier to outsource than others? I can imagine that a finance department might be easier to outsource than an IT

 organization or a network.

[Marco van Velthoven] (11:57 - 13:07)

What you see a lot, the model we have used in recent years, is the maturity of your product. If you have a mature product with few iterations and it is primarily in maintenance mode, it is easier to outsource than when you are still in full product development. Where you have many iterations and a lot of communication with the customer. If you look at organizational parts, you can look at operations. Operations are easier to outsource, where you set SLA's, KPI's with an offshore party and manage them accordingly. But when you are innovating, when you are making major changes to your software, involving a lot of collaboration with your business, it's more convenient to keep it close by.

[Hildo van Es] (13:08 - 13:41)

Yes, I understand. Are there certain forms of outsourcing that you find more pleasant to work with, or that you think contribute better to a healthy organization? For example, I can imagine that insourcing, so on-site sourcing, is more pleasant as an IT manager than outsourcing everything.

[Marco van Velthoven] (13:42 – 16:01)

Yes, there are two periods in my opinion. We have a period before 2019-2020 and a period after 2020. What I have observed is that there was a lot of resistance to nearshoring or offshoring in the pre-COVID situation. Product people, but also IT professionals found it very difficult to collaborate with such clubs, and there are some nuances to that, which I'll come back to later. After COVID, working via Teams, everyone remote, has become ingrained and has remained. It is more common now, making it easier and more accepted not to be all in the same location. This has had significant implications for sourcing in general, and for costs as well. Nearshore costs have risen significantly, offshore also a bit, but not as significantly. If you then look at the preference, the preference goes to outcomes. From my experience, I see different outcomes with nearshoring not really. With offshore, it depends on how you have organized it and how you manage that model. There are more hooks and eyes than with nearshore, especially cultural aspects. So, at the moment, my preference is for nearshore and a mix of local people, a hybrid model. Where you can go to India for maintenance and operations, and for niche things like PEGA, which is also good to outsource to India. That would be my ideal model at the moment. Also spreading your risk across different continents and ensuring that you follow the sun principle.

[Hildo van Es] (16:01 - 17:32)

Yes, it’s interesting that you mentioned a mix of people here and there. I recently spoke to someone from Levi9 who said they had issues with people from Ukraine coming to the Netherlands due to the war. This is a risk for a nearshore party like Levi9, but it can also be an opportunity where they have a team there and people here. I see that indeed. In my experience, communication is quite an issue with nearshore parties. I have worked a lot with nearshore parties and communication is quite a thing. What do you think about communication and distance, both in language, geography, and culture?

[Marco van Velthoven] (17:32 – 20:10)

Distance, as I mentioned earlier with COVID, has become an irrelevant factor in my opinion. Communication is very important. You correctly pointed that out. It's about people having purpose and context in what the company does. Many tech companies now work quite a lot remotely. It's important to maintain a connection with the product. That mainly involves ensuring communication is such that you can clearly define the point on the horizon. Where is the organization heading? And when you bring it down to the individual developer or architect, what is my contribution to that point on the horizon? I think it is essential that successful companies working with different sourcing models in a hybrid model are very good at translating the business strategy into what a developer ultimately contributes. If you do that well, it doesn't matter if you have nearshore, offshore, or in-house development as long as you are mainly working remotely via computer or Teams. What is essential is that you have a man on the ground, a proxy PO, who can help with ad-hoc questions and answer them directly. You shouldn't need to make a call to someone who is hard to reach or unavailable because they are busy with other things. And another important point is that you shouldn't body shop with a nearshore or offshore party. You should give full mandate for a part of the product to that team, set up a full team that can develop the product, and have a proxy PO to translate. Quality assurance and T-shaped developers should also handle the DevOps part.

[Hildo van Es] (20:10 - 20:37)

Yes, and what do you do when deliveries, for example, fall short? I have experienced in the past that you start with great developers and halfway through the project they are all replaced by less competent ones, leading to degradation in the quality of the product. How do you deal with that?

[Marco van Velthoven] (20:37 – 21:54)

Yes, I think we all have faced this if you've been in engineering and management for a long time. People change, especially in nearshore parties. There are several things you can do against that. You can make agreements with the vendor at the start. There are, of course, some things you cannot control if people leave the company. Establish your confidence, so you have strategic, tactical, and operational meetings. The operational meetings focus on outcomes. What is expected? And knowledge retention. In the parties I've worked with to counter this, I have always stipulated that there must be a knowledge transition. As an organization, we can also say if a developer is not good enough, they need to be replaced, providing you with several instruments to work with. Naturally, this mitigates part of the risk but never eliminates it completely.

[Hildo van Es] (21:55 - 22:21)

Yes, it’s a good idea to look at a proper organizational model and knowledge retention. What is your experience or vision on the knowledge level internally and externally and the harmonization between them?

[Marco van Velthoven] (22:22 - 24:04)

The knowledge level generally depends on the complexity of your product. Some products are very complex and take a while for people to get up to speed both internally and externally. It's also individual; some people pick things up quickly, others less so. You need to weigh that. Over time, you know the learning curve for each product. When it comes to communication, especially overseas, we always had teams in-house for a week or four weeks to quickly raise the knowledge level with a few experts, ensuring the output is quickly there. You always need to see if the output is there, if it’s understood, and if the right value is created by that team. This brings additional costs, but it is a positive business case. You need to get the knowledge level on par as quickly as possible. That doesn't mean that nearshore people are less intelligent. It's mainly about communication and working together, sometimes looking each other in the eye.

[Hildo van Es] (24:04 - 24:29)

Maybe the bond is stronger if you are on location at the organization. But there is also a significant risk with external staff. If they build up a lot of knowledge and then leave, how do you view that? How do you manage that?

[Marco van Velthoven] (24:30 - 26:03)

With external staff, you have groups of freelancers and collaboration with parties like Levi9, Netron, and Accenture. With these parties, you can agree on knowledge retention. Freelancers shouldn't become a single point of failure. This happens often; companies become very dependent on an individual who holds the knowledge. Internally, nothing is organized to transfer that knowledge. There’s no plan B. As a responsible person, you must intervene and ensure that your organization retains that knowledge. Either internalize it or ensure that it is with one of your partners who guarantees continuity. This mechanism needs careful control, but you must also have the courage to occasionally say, "This person has been here for five years, holds a lot of knowledge, and if they leave, things will fall apart," and then decide to let them go and see what happens.

[Hildo van Es] (26:03 - 26:24)

Indeed. You work at a large organization, a multinational. The common model is to work with intermediaries. Why would you choose an intermediary? Why not do it yourself as a large organization?

[Marco van Velthoven] (26:25 – 28:21)

The main reason is capacity. Is your HR organized to handle a large influx at once to recruit? It takes a lot of time to find the right candidates. Additionally, some people specialize in finding the right talents in the market, and if you have a relationship with them, and they find the right profiles, that can be very useful. But you must avoid dependency on one vendor. It’s a significant risk. If, for example, you have many people from the same vendor, and that vendor goes under, many freelancers are affected, and your company faces a reputational risk since they work for your company. The intermediary is just that, an intermediary. If there are issues with payments, since you pay the intermediary, your company gets the blame. That’s why you should spread that risk. Don’t place it all on one entity. Look at whether they are a group of companies with the same financier or are truly independent, allowing you to mix local and nearshore companies. This risk needs to be spread out. Don’t

 rely on one nearshore party, but have at least two to compare and scale up if needed.

[Hildo van Es] (28:21 - 28:39)

Yes, scaling is possible. But you also want to limit the risk of being held hostage by an intermediary or another supplier. That applies to all vendors, but it's particularly critical with sourcing.

[Marco van Velthoven] (28:39 - 29:03)

Especially with sourcing. With packages, sometimes you can't avoid it. That’s just a fact and a choice in your architecture. For example, if you choose a package, we know it’s hard to cut out. But when it comes to people, your sourcing, you can easily prevent that. Design your strategy so that you don’t have that dependency from the start.

[Hildo van Es] (29:04 - 29:31)

Exactly. There can be an interesting tension when using intermediaries. An intermediary has a contract with the organization to which it supplies people, but also with the freelancer. How do you experience that tension? Do you find it difficult?

[Marco van Velthoven] (29:32 - 30:17)

It’s a tension you shouldn't underestimate. I’ll give an example. Annually, people want to review their rates, want a change. The ICT workers are working for your company and come to the line management. Ultimately, we are not the contractual party for that freelancer; it goes through the intermediary. The intermediary might see it differently, taking a certain margin. What I usually agree with the intermediary is, after a year, a portion of the margin decreases, but we pay the same, fair since the initial recruitment costs are recouped in that year.

[Hildo van Es] (30:17 – 30:21)

Yes, and they want to earn too, which is logical.

[Marco van Velthoven] (30:21- 31:19)

Normally, that process is transparent and straightforward. You direct the freelancer to the intermediary, and they sort it out. As a hiring party, you don’t want to deal with it. But in practice, there are conflicts in the contract between the intermediary and the freelancer, leading to situations where line management is also confronted with it, which is why you have an intermediary, to avoid this. You want to focus on your product, on development. You outsourced that part. That’s a crucial factor in vendor selection and why you want to avoid lock-in. If it happens too often, you might need to part ways with such an intermediary.

[Hildo van Es] (31:19 – 30:21)

Yes, but that’s not always possible, especially if an intermediary has many people in your organization and a non-compete or relationship clause. If you part ways with such an intermediary, you also part ways with all those people in your organization.

And that brings us to the end of this podcast. Marco, thank you very much for the great conversation, and if you, as a listener, would like to continue the discussion or have questions, please contact us on LinkedIn. Thank you for listening, and until next time.