Part of this interview was originally published on HackerNoon.
Philippe Peron is our Chief Delivery Officer. 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.
In the interview below, we’ve asked him questions about his tech career journey and people management experience, how to build and manage highly productive extended and distributed Agile teams, why you need to consider your dispersed IT team as a product to succeed, and what sets a software team distribution model apart from other outsourcing engagements.
Enjoy the conversation!
Philippe, how did you get to the world of tech and why?
A long time ago in a galaxy far, far away… when I was 11, I received my very first computer as a Christmas present.
It was a home computer (Commodore 64). At that time, there were magazines (hebdogiciel) that I could buy at a kiosk. They 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 was taking me literally weeks, entering 1 character at a time … and of course, at the end, there were some typos that generated some errors and took ages to find. What a lot of fun.
By the way, at that time, games were sold on audio K7s and therefore … could be compiled and copied with a stereo system as you would do for music albums. I’ve never done this myself of course…
Also, I went to an IT club while in Middle School in France where I learned and actually understood the basics of coding aka If, then, else, loop, goto (yes I know it’s bad), “hello world” etc …
This was my first experience in the IT world. Then my uncle who was working at Hewlett Packard gave me my first real PC (HP Vectra CS), which was absolutely not trendy when everybody else was enjoying Atari, Nintendo, or Sega. PC wasn’t for gaming at that time and this was a “boring” computer with flat floppy discs that couldn’t store much. I began experimenting with some more sophisticated programming using that “machine”. As there was no Internet yet, no chance to get any technical inspiration or support online or browse media channels for audio and video content = books, books, and books.
When I went to high school, I got my first real programming skills developing programs with functions and procedures, and with at last some graphical complexity.
In general, I carried on with 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, that’s where I got a full spectrum of skills such as Systems & Networks, OOP, Databases, etc. These were the years when the Internet revolutionized the world.
After that engineering school, I got my first job at Amadeus, now a leading travel tech company. It was a global reservation system, providing flight booking services for connected travel agents/agencies. 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. Assembler is a very strict language, you need to be very disciplined and know exactly what you’re doing to work with it. Even the smallest mistake could be crucial as Assembler is very time-consuming to debug. My first three years in programming as a professional consisted mostly of Assembler and a little bit of C and C++ experiences.
After Amadeus, I joined a Fintech startup. Well, this term wasn’t as well-spread as nowadays back then but the company’s name was Finance Technology anyway. 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, i.e., when you look at charts highlighting different periods in stock markets and can identify certain trends. And those trends were supposed to help individual investors understand what could be the future value of this stock market asset.
We were selling such content to a website that was an equivalent of Google in France, voila.fr (by France Telecom). That portal was the main 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 get generated text with stock market “forecasts”. All that content was based on our technical analysis formula.
Unfortunately, that startup was lacking funds at some 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-yachts industry. At that time, mega-yachts were the ones ranging 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 for building the boat: screws, paints, engines, etc, track costs, save technical documentation. Then, once the yacht was in operation, support administration of crew members, various operations and most important technical maintenance of engines.
Our software was helping 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 afterwards when the boats were at sea or at the shore. I had amazing experiences cruising on those boats when they were moving at 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. As a result, I had a couple of free cruises on some of the most luxurious boats in the world. As an engineer, I learned a lot about Systems & Networks, APIs and Databases synchronization and developed some other skills while performing a wide range of tasks, from wi-fi installation, network cabling to servers installation and configuration.
It was both challenging and enriching.
After that, I joined an e-commerce company called ricardo.ch. At that time ricardo.ch was by far the #1 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 Developing as well whenever needed. This is where I got my first experience as a manager, after 3 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 gain firsthand experience with 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 stakeholders of a Ukraine-based tech provider that was appealing 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. After having some calls with the provider’s management team, he liked their attitude and the overall culture and delegated me to go and explore the opportunity in Ukraine and help him make the final decision.
After I visited the potential partner and talked to some of their developers, I was impressed with their passion, their open mind, and willingness to be real contributors to the success of the project. I really liked that spirit and told my boss I was OK to go with outsourcing 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 and work closely with the team.
I was building a team from scratch between 2011 and 2014 and grew it up to 35 resources, mainly .Net, some JavaScript, some BI and QA guys and girls as well as some mobile developers. There was a change in management in 2014.
The new CTO wasn’t that supportive of outsourcing. As he had a different strategy in mind, it didn’t last long before we said goodbye to each other at the end of 2014. By the way, ricardo.ch closed their team in Ukraine about a year later.
At that very period, I accidentally met a Director of Just Eat, UK’s leading foodtech company, that had its own extended team in Ukraine with a Top 3 outsourcing provider. He eventually invited me to join their company in the same position I had at ricardo.ch (Site Manager). I agreed, they put me into a 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 a different company size, different outsourcing objectives and overall ambitions. The team of 25 people was already there, so 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 the London-based core team, at the end of 2014 – 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 and balancing risks and influences was the right thing to do, staying 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 talents in the UK and other factors, the Kyiv team was back under the spotlights.
When I joined in 2014, there was a team of 25 people. When I left in 2018, the team was more than 85 specialists. Now they’re more than 100 people in Ukraine.
After my 4-years journey with Just Eat in Ukraine, I’ve joined Evolve beginning of 2019 as a Chief Delivery Officer.
Since you’ve been working in Ukraine for a while, what makes this experience interesting?
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 is a specific country in terms of labour law. If you hire somebody who passes a trial period, that’ll be next to 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 the expectations anymore. In most cases, you have to pay a salary to a dismissed employee for several months as a redundancy.
What if your company goes through some financial turbulence, you shouldn’t have to wait to be bankrupted to pilot it. This creates a huge risk for small companies and adds painful constraints to solid businesses. 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 notice depending on your contract to dismiss an employee who doesn’t meet expectations. Coming to Ukraine helped me to 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 contractor (depending on locations). Even if clearly this wasn’t the main deciding factor, it eased the orientation of some of 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 that in 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’re doing. You can rely on them and they will show initiatives 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 contributing their engineering skills and technical experience in order to contribute to the project’s success without over-engineering. 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.
In Ukraine, like in other countries, years of experience are not always reflecting the Seniority level of Developers. You can have somebody with 3 years of experience in Software Engineering who’s much more mature than one with more than 7 years of experience. In Ukraine, developers who position themselves as senior may not be as T-shaped as you would expect.
Sometimes, after several months of exposure to a specific ecosystem, they still lack understanding of the Business purpose(s) for their contribution and this can be quite frustrating when there’s no orchestrator (PM, TL, SM) to compensate for this. You need to be clear with your expectations at recruitment time or be ready to inject extra management time and effort later on… I expect Middle and obviously Senior developers to build in a timely manner a decent vision of the Product(s) they’re contributing to create and optimize, to take ownership of their work, fill the gaps wherever needed based on their own experience or simply raise an exception (to use some development terminology).
Sometimes they may have a tunnel vision, restricting their scope of responsibilities to their area of expertise (Mobile, Front-End, Back-End, etc) without seeing the bigger picture. I’m not talking here technically aka full-stack vs. non-full stack.
As a modern leader, I focus on delivery AND I believe in Agile concepts like Management 3.0 (Jurgen Appelo). I’m doing my best to avoid situations requiring top-down involvement. For sure the new generations of smart Ukrainian engineers are very receptive to and compatible with such an approach but sometimes it’s harder than I thought. If you have any doubts about somebody’s level of understanding which will surely affect directly or indirectly the level of contribution, just ask that person Why he/she is doing this, what is the purpose of the User Story/Task, within the scope of the Project and/or Product.
There are unfortunately hard times when you need to realize whether you should invest in developing a Team member considering his/her potential or if it’s “too much” effort compared to the Management capacity, as rough as it sounds.
Anyway, as usual, retrospectively everything starts with recruitment …
Another thing is that sometimes it’s difficult to get transparent feedback due to high respect for the so-called hierarchy. This is a clear cultural difference with for example France and you must insist on this to happen in order 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 as well motivate Team members to voice their ideas during technical discussions and increase their self-confidence.
It’s obviously helpful to use elements of the Scrum framework (sprints, sprint plannings, daily meetings, retrospectives, feedback sessions, etc).
What I like seeing is when developers know what they’re doing AND most important WHY, inject their experience and help stakeholders achieve great goals. That’s what we consider in the first place when we’re hiring for clients’ extended teams or bespoke software project teams require of our developers in the UK and Ukraine to ensure each solution we deliver adheres to the highest standards of coding and software engineering.
Would you like to learn more about how we work and make a difference?