Consider Your Distributed IT Team As a Product: Interview with Philippe Peron, CDO

Philippe Peron is a Chief Delivery Officer of a Leicester-based software house Evolve. He has almost a decade’s experience with building and managing Agile development teams from both the customer and service provider perspectives.

In his tech leadership roles at ricardo.ch, the Number One marketplace in Switzerland, and Just Eat, a leading British food tech company, Philippe has learned many invaluable lessons from managing and scaling extended software engineering teams and dealing with issues like resistance to change, cultural gaps, etc.

Some of these lessons are definitely worth sharing with fellow hackernooners and the rest of the world. So I’ve tele-interviewed Philippe about his career journey and passion for IT, tech leadership, how to align in-house and extended IT teams and make them work in concert to deliver above expectations, and more.

Enjoy the conversation!

Philippe, how did you get to the world of tech? Was it always one of your passions?

A long time ago in a galaxy far, far away… when I was 11, my parents gave me my very first computer as a Christmas present.

It was a home computer called Commodore 64. At that time, there were magazines (called “Hebdogiciel”) that I could buy at a kiosk which contained hundreds and hundreds of lines of code that I could type and save. So I used that code to create some very basic programs. It literally took me weeks to complete, entering one character at a time … and of course, in the end, some typos generated errors that took ages to find. What a lot of fun! 

While in Middle School in France, I went to an IT club, where I learned and actually understood the basics of coding -- If, then, else, loop, goto (yes I know it's terrible), "hello world," etc...

This was my first experience in the IT world. Later, I began experimenting with some more sophisticated programming using the first real PC called HP Vectra CS. It wasn’t for gaming at all, so it wasn’t considered trendy at that time. As there was no Internet yet, there wasn't an opportunity to get any technical inspiration or support online or browse media channels for audio and video content. We just had books, books, and more books.    

When I went to high school, I got my first taste at "real programming" by developing programs with functions and procedures, and at last, some graphical complexity. 

In general, I carried on on the same path; I went to an IT university in 1990; after university, I went to an IT engineering school in Paris. This time, it was much more serious. It wasn't just about programming. Here, I got a full spectrum of skills such as Systems & Networks, OOP, Databases, etc. These were the years when the Internet revolutionized the world. 

And what was your first job in IT?

After that engineering school, I got my first job at Amadeus, now a leading travel tech company. I went deep into learning a real-time operating system for mainframe computers from IBM (TPF) and Assembler language for microprocessors. It was my first official commercial experience. My first three years in programming as a professional consisted mostly of Assembler and a little bit of C and C++ programming. 

After Amadeus, I joined a Fintech startup. Well, this term wasn't as well-known back then, but the company's name was Finance Technology, so it rings a bell. There I was in charge of databases and exploitation of data, so it was almost like a mix between Data Warehouse and Business Intelligence.

We got data about different stock markets from real-time streams, I saved all that data into databases and then I developed a program that would analyse all that data and provide automatic technical analysis. 

We were selling such content to a website that was an equivalent to Google in France, voila.fr (by France Telecom). That portal was the leading search engine in France in the early 2000s. It had several sections like news, horoscope, weather forecast, and finance. When someone would click on a chart, they would be able to see the stock market forecasts. All that content was based on our technical analysis formula. 

Image source: www.macg.co

Unfortunately, that startup lacked funds at a later stage, so I was dismissed along with other colleagues. Anyway, as far as I know, the technology's IP was acquired afterward by a large financial institution, and some of the founders were rewarded for all their efforts.

After that, I went into something a bit more "exotic." I got a job in the mega-yacht industry. At that time, mega-yachts were ones that ranged from 60 up to 90-100 meters in length. Now there are much longer superyachts, but at that time, only up to 10 people in the world owned the ones ranging between 90 and 100 meters. Those yachts had IT needs.

During the construction, they needed an ERP-like system to keep track of all materials used to build the boat, like screws, paints, engines, etc. They also needed a way to track costs and save technical documentation. 

Our software helped those boats to operate and structure all critical information. I was developing and installing that software, either during the construction phase in shipyards around the world or afterward when the boats were at sea or onshore.

I had terrific experiences cruising on those boats when they were sailing across the sea. I just embarked on the boat with my backpack and essentials for 2-3 days, as I never knew when I'd be done with my installations. 

After that, I joined an e-commerce company called ricardo.ch. At that time, ricardo.ch was by far the number one e-Commerce website in Switzerland, before eBay. They had an R&D center in the South of France. I was hired mainly as a DBA (MS-SQL) and was writing code as needed.

This is where I got my first managerial experience. After three years, in 2008, I got a couple of developers under my lead, and since then, my passion for leading people never stopped growing. ricardo.ch was the company that made me understand more about outsourcing, and I gained firsthand experience working with Ukrainian developers.

As ricardo.ch was growing and thriving, they needed more tech resources to ensure their roadmap achievement. However, top management didn't want to invest 100% of the company's R&D budget into the French team. In 2011, I was tasked with going to Ukraine and meeting with a nearshore provider that appealed the most to our CTO compared to other providers in the shortlist.

That CTO was young, agile, and pragmatic, he didn't fear outsourcing and going East. He asked me to go and explore the opportunity in Ukraine and help him make the final decision. 

After I visited the provider in Ukraine and talked to some of their developers, I was impressed with their passion, open mind, and willingness to be real contributors to the project's success. I really liked that spirit and told my boss I was OK to move forward with outsourcing development to Ukraine. In September 2011, I started traveling every week back and forth from France to Ukraine until the decision was made to relocate me permanently to Ukraine to work closely with the team.

I was building a team from scratch between 2011 and 2014 and grew it up to 35 resources, consisting of .Net, some JavaScript, some BI and QA guys and girls as well as some mobile developers. Then there was a change in management in 2014. The new CTO wasn't as supportive of outsourcing and had a different strategy in mind. So it wasn't long before we said goodbye to each other, and that finally occurred at the end of 2014.

By the way, ricardo.ch closed its Ukraine-based development operation about a year later.

During that period, I accidentally met the Director of Just Eat, UK's leading FoodTech company, that had its own extended team in Ukraine with the same provider. He eventually invited me to join their company in the same position I had at ricardo.ch (Site Manager).

I agreed, and they put me into the recruitment process, and that's how I started my second outsourcing adventure, still as a customer, with the same provider in the same building … just on a different floor. 

However, this time everything was different, as Just Eat had different outsourcing objectives, overall ambitions, and the company was also not the same size. They already had a team of 25 professionals when I took it over. After being adopted by the team, my fantastic journey started. 

Just Eat planned to grow their Ukrainian team, and also decided to open a third development centre in Bristol as an addition to their London-based core team. This was around the end of 2014 to the beginning of 2015. That triggered some adjustments between the different locations. After the Revolution of Dignity (Maydan), Ukraine was considered as a country with potential instability, so balancing risks and influences was the right thing to do, to stay aligned with a successful IPO in 2014. 

Since the IT growth was more focused on the Bristol team, the acceleration was more visible on the UK side. However, a couple of years later, due to the shortage of the right match of skills and talent in the UK and other factors, the Kyiv team was back under the spotlights.

When I joined in 2014, they were a team made up of 25 people. When I left in 2018, the team was composed of more than 85 specialists. Now more than 100 professionals work in Ukraine.

After my four-year journey with Just Eat in Ukraine, I joined Evolve at the beginning of 2019 as the Chief Delivery Officer.

Since you've been working in Ukraine for a while, what makes this experience enjoyable?

When I first came to Ukraine, I was a fresh manager facing issues with talent acquisition in France. The speed of hiring was slow, the cost of resources was high. Moreover, France has specific practices that must be followed to be in line with the country's labour law.

If you hire someone who passes the trial period, it'll be near impossible to dismiss them if you find out at a later stage that they aren't the right fit for your company or aren't meeting your expectations anymore. In most cases, you have to pay a salary to a dismissed employee for several months as redundancy. But what if your company goes through a period of financial turbulence? You shouldn't have to wait to be bankrupted to pilot it. This creates a huge risk for small companies and adds severe constraints to solid business models.

I don't mean that it's good to fire people on the fly, not at all. However, as an Agile decider, you should have a little bit of flexibility swapping underperforming team members or recalibrating your IT costs when needed. In France, it's almost impossible. 

In Ukraine, you have a 14-days or a month-long notice period depending on your contract to dismiss an employee who doesn't meet your expectations.

Coming to Ukraine helped me contribute in a pragmatic way to the IT strategy of ricardo.ch by hiring faster and balancing HR risks. 

At Just Eat, we were benchmarked with UK-based recruitment. From a Finance Department point of view, when trying to compare apples with apples, the cost of a private entrepreneur in Ukraine (contractor profile equivalence) is between 30% and 50% cheaper than the cost of a UK-based contractor (depending on the location).

Even if clearly, this wasn't the main deciding factor, it eased some of the pressure on the IT budget. From a management perspective, an extended team is considered as an organic extension of an in-house team and treated the same way. So it shouldn't create any extra burden as long as one of your main hiring criteria is a cultural fit and obviously as long as your organisation is mature enough to be extended.

And how does the quality of Ukrainian developers compare to France or the UK?

It's a good question. It's not about quality, but more about maturity, and maturity is a complex topic. In Ukraine, software engineers aren't as "talkative" as in France, but they're good at what they do. You can rely on them, and they will show initiative if properly empowered and/or coached by management. They won't consider their job done by "just" processing the backlog.

They seek constant improvements by investing in their engineering skills and technical experience to contribute to the project's success without over-engineering it. In this way, they're similar to the UK engineers, except that the British engineers are better at making themselves visible and being self-managed in general.

Sometimes it's difficult to get transparent feedback because of their significant respect for the so-called hierarchy. This is a clear cultural difference with, for example, France, and you must insist on this to happen to get the best of your relationship with team members. It's a win-win situation as it helps everybody to get better, even though sometimes you'll need to forget a bit about your ego.

This will motivate Team members to voice their ideas during technical discussions and increase their self-confidence.

What I like seeing is when developers know what they're doing and, most importantly, why. I always appreciate when they can offer insights from their experience to help all stakeholders achieve their goals.

You have the advantage of looking at Agile teams both from a customer and provider perspective. So what's your secret to avoiding project failure?

The extended team model implies that at some stage (when reaching a certain team size), the recruitment of a "local authority" (Site Manager, Delivery Manager) to manage and coordinate teamwork on-premise is key. Indeed remote collaboration relies on the solidity of the virtual bridges that you build cross-locations. Addressing distance and obstacles between the distributed teams is one of the critical aspects of it. Hiring the right profile offshore, as a trusted and radiating proxy of your company's culture is undoubtedly another vital aspect of this process. 

As a customer, you are the primary influencer, actor, and motivator. You and not your outsourcing partner! You need to inject your corporate DNA into your extended team(s) to ensure that you are getting the expected value for the money you are investing in. 

How to avoid failure? It depends on what you're trying to achieve. If you come with a long-term need, this is when you have to think about the effort you'll need to invest in your extended team to make it a success. Again there's no miracle. I'm not talking about money here. You can have a lot of money but end up having a complete fiasco.

You need to make sure that when you're engaging in a long-term relationship (12 months plus) with the company that will be operating your extended team, they understand your culture, as it's crucial for your team's success.

As a client, you need to make sure that you have enough capacity internally to connect your remote team into your corporate culture and environment in general. As surprising as it sounds, very often, companies realise while suffering from their extended team integration that they have no corporate culture or at least not as adopted internally as expected. Or what they discover is that problems they may be having with the extended team are mirroring existing internal issues.

Unfortunately, your onshore team might be quite resistant to what could be perceived as a threat or unfair competition. Honest and transparent communication from management on that topic (real reasons, plans) is mandatory to get buy-in for employees, or you'll set yourself up for failure.

I had a similar situation at ricardo.ch, but it went well, thanks to my status as their former colleague (although they didn't like me that much when I was growing the team in Ukraine (laughing). I also had strong support from my CTO and other managers who helped convince the team that their extension would be good for the company and for them.

Very soon, the Ukrainian side was considered as part of the family, the French team bought-into this engagement and had no more concerns about their future. 

Before embarking on a team extension journey, you should be ready to go through some painful moments, from something going wrong with recruitment to onboarding the newcomers to having to dismiss someone along the way.

All these points have to be anticipated and clearly discussed with your service provider.

Be focused and persistent, be fair and supportive, and don't let any walls separate your teams. Communication is the cement that builds a strong foundation. Consider your distributed IT organization as a product. Like any product, you build it, inspect it, and adapt it.

So, as I've already mentioned, it all depends on what type of need you have. If you have a project in mind for just 6 months, it's OK to go ahead and hold your provider accountable for your project delivery. Check their portfolio, ask for references, review their existing products and solutions. Find out how many projects they've delivered and how they've delivered them. Find out if there were any delays.

Beware of the fixed-price paradox: when you aim for a fixed cost, but can never reach it for some reason. You either have to pay more, or your provider has to inject more resources at their own expense or both. 

However, there can be an engagement evolution from a managed project to an extended team. If you're a startup and only have funds to build your first MVP that needs to be delivered in less than six months and can't have a long-term roadmap because of financial unclarity, you need to start somewhere. So you can engage a third-party provider for MVP development, and later, when you attract more funding, you can convert your managed team into your permanent extended team.

And again, the same story about the culture, team integration, etc.

Should you have any additional questions or enquiries, you can reach out to Philippe Peron directly on LinkedIn.

Also, check out a female CTO sharing her thorny journey in the male-dominated tech world.

Do you have a tech career journey that deserves a shout-out? Get in touch and I'll be happy to interview you for my next story on HackerNoon!