2006 was the very beginning of Talend, and CTO Cédric Carbone set to work together with another dev. engineer. Six months later version 1.0 was out on open source GPL licensing. Fast forward 8 years later and Talend had become an international company with over 200 engineers.
But that’s not all there is to it. Talend is now listed on NASDAQ and Cédric Carbone, eager to jump back into the rapid growth of early company stages, created Influans in early 2015 with other former Talend colleagues, and has been focusing on building its cloud platform since. Influans provides a turn-key cloud platform to increase thirtyfold the efficiency of digital marketing, so big data is still at the very core of his current company.
Thus twice charged with scaling technology and engineer capital at the same time with Talend and Influans, Cédric Carbone shares how to build a vision for a tech company that aims high, and walks us through the background framework to building a team to deliver it. And as everything changes, he explains the care needed to hold culture constant while organising new processes to help the team and product grow.
Some thoughts on a tech company vision
1) Technology zeitgeist
“When a new technological stack arrives, new pains can be addressed” Cédric explains. “Influans was launched 2 years ago because it is when real-time big data became possible. Were it launched 5 years ago, we would not have had the appropriate technology to build it. Another example: I currently receive way too many emails. How do I sift through them all to find the ones that need my attention to get things moving? This pain is not solved for now. Maybe in a few years time we’ll have the cognitive software capabilities to do so, but not for now.”
A CTO is thus able to spot technological ruptures coming up on the market and link it to a specific pain. Cédric specifies that “Once you have the technology, that you know you can build a product that is an answer to a pain, here you go, you can get started and it’s now the VP of Engineer role to deliver. One of the pains we addressed when launching Talend was company dependency on external proprietary code that needed to be deployed and monitor in addition to the company’s own code. Talend is a code generator, it does the work for you in different languages, starting out with perl and java. It is not Talend specific code so tech teams can dig into it and monitor it with their own tools to ensure performance. It was a big disruption on the market from day one. Then, we started on big data very early on, before everyone got into the market.”
So a CTO makes a bet ahead of time. Cédric warns that “it will be harsh on the business sides as sales people cannot really sale anything. They evangelize the market during a couple of years. But then when the market gets it, when every tech player wants to cram in and is getting ready to develop a new product in 2 years time, this is when you’re in a good position. You’ve got case studies and your product has gone through multiple versions with customers feedbacks.”
2) A daring roadmap
A tech company foreseeing the state of technology ahead of time can aim high. If you do so and your business starts scaling, you’ll find that you really need to sustain it with a legitimate product. Your own newborn product is omitting use cases that you need to address very quickly. And so your engineering teams develop together with the growth of your business. “It was especially the case for Talend” he says, “we were aiming high and our product came up against market leaders that had been around for 10, 15 or even 20 years. So very early on we invested in R&D because we needed a product able to compete at the same level as the ones of IBM of Informatica.”
And the nurturing circle between tech vision and aiming high did not stop there for Talend. “From 2008 on we would launch a new product line every year. Coming from the data integration and Extract Transform Load world we went after data quality in 2008, Master Data Management in 2009, Entreprise Service Bus. in 2010, and then Hadoop big data in 2011, Bus. Process Management in 2012… Obviously some areas of development did not even exist when we launched Talend in 2006. Technology and pains were completely changing over time and we had to adapt”, says Golden.
Even if chosen markets are related, getting a new product out and running every year means studying a new market, new competitors, and organizing new client interviews every year. “So each year is like the first year of your startup, but you still have to improve your existing products so that they catch up fully to market leaders,” Cédric points out. So there is no way around it: the engineering team needs to scale and deliver.
Once a tech vision has emerged and a daring roadmap comes to light, it needs to be delivered. But how? Cédric sums it up this way: “it gets delivered through people and the methodology for these people, culture.”
1) Heads on straight
Scaling a team means that you’ll often end the year with twice as many people that you had in store at the beginning. “If you start the year with 60 engineers, you’ll end it with roughly 120 team members. You need to be very much aware that solely doubling the number of people in your team to deal with a doubling workload does not work. The same processes cannot be applied to a team of 10 and a team of 50 or 100, least of all 200.”
As methodology in your tech team changes, you’ll need to spot leaders that had a specific job one year and can deliver at a completely different job the following year. They are the ones on whom you’ll be able to lean on. “If someone is scrum master for a 5 people team and they become scrum master across 3 teams of 30 members, their job is changing”, Cédric says.
Getting people that can grow, adapt and think properly onboard is more important than hiring profiles that are perfectly adapted to a job description. “Maybe they’re a perfect fit for the job you’re hiring for now but in one year time they won’t be anymore. So definitely go for the person that is less of a good fit for your initial job description but who will know how to adapt and grow, and with whom you can have a trusting relationship.”
Good hiring is key to your team and product growth, so don’t be overly focused on your defined target Cédric warns. “If the plan is to get 60 engineers on board, don’t be overly fearful of your board. You’re better off with 50 good hires than 60 hires that include 10 who are not the right players for your company. Not being on the same wavelength and mood, they will be out of sync with their co-workers and will negatively impact your team.”
Asking people to evolve and adapt to new jobs is not a simple thing to do, even if it is something of a promotion. “From developer to manager, to manager level 2 and to department head, you’re requiring different levels of personal involvement”, Cédric says. “Allocation between the private and company spheres changes over time. Their salary may be doubled, but some will not accept the offer. It’s also quite amusing to note that different cultures favor different reactions to career evolution. As a general rule in some countries, if you promote an employee to a director role, they’re likely to answer no, while in other countries, employees would start taking on the challenge before even being promoted.”
A way to quickly scale engineering is by acquiring a company. “As a bonus, it can also scale business with local sales forces. In 2010 we acquired Sopera, a 60 person company in Germany. Germany is a large european market for open source, but is a very decentralized country. So acquiring them also meant directly growing our business impact.”
Upon acquiring a company, a number of people that had a common culture become part of your company. Make additional efforts to involve them and to make it clear they are considered as key contributors to your team: there’s a reason why you were interested in their technology. “When we acquired Sopera, we moved the Q&A to Germany”, Cédric says. “We also set up the Tools & Methods department over there, with everything related to methodologies, automation and sysadmin it hold an important impact on Talend. All of it was set up in Germany.”
Cédric explains how Talend really worked on closing gaps between their two company cultures. “We really wanted our new employees to feel as important as anyone else. You need to reinforce team feedbacks. I took 3 direct reportees in Germany – at the time I had approximately 10 reportees spread over different countries.”
“The 6 months following Sopera acquisition, as long as I was in France I would also go work from our Germany office one day a week. Even if no working session or meeting has been planned, they know you’re here and that you’re committed to them. You get the chance to have breakfast or lunch with the team and get to know people individually. It would be long days for me, taking the 7:00 am flight in Paris CDG airport and being back home at 11:00pm. But this is the only way to get feedback and understand what’s going on.”
Make sure that horizontal communication is also happening between teams. Communication is even more critical to get right when teams work on different time zones. “Between our Chinese and French tech teams we had something like 2 hours common working time. It does not give much opportunity for communication. Even without time zone difference, when realizing that teams are sending Zendesk support tickets to another team they never actually talked to, and that the other way around, the support team is spending 50% of its working time answering tickets for a team they never even phoned and have no idea what their objectives are, you know something is wrong. It is probably not the most efficient setup. First suggest to your teams to speak to each other. After a while if they still haven’t, directly organise the meeting yourself.”
Internationalization is another good way to scale an engineer team. “Talend having raised enough money right from the beginning, we were able to hire 10 people in China pretty much right away. China was chosen partly because our first developer was interested in living there.”
Getting involved in different countries allows you to get the proper talents you’re looking for. Cédric says “we worked in China from the beginning. We developed Ireland and several states in the USA where you can find high committer profiles that tend to work from home. And with Germany came Ukraine and Belarus.“
Talend team purposefully tried to split products in different teams over differents countries. They did not wish big component teams to be in one single country. “The plan never was to have for ex. Data integration in France, MDM in Germany, data quality in China and so on. If a product goes through high growth and you need to hire 30 new people in a single location, it’s a huge strain on a single team. Whereas if you need to recruit 10 people in Paris, 10 in Berlin and again 10 engineers in Beijing, it’s much easier for everybody. It is also good for knowledge transfer as it’s way easier for people to understand what other teams are working on when sitting next to them. If your colleague is working on another product 5,000 km away, what are the chances you’ll understand what his work and product challenges are? So we paid attention to splitting our product lines over several countries. For example, until 2011, each time we launched a new product, a corresponding team would be set in China.”
So internationalization is a scaling advantage. But Cédric points out you need to make it work, “You need to be there, to be interested in the local culture, and to adapt to it. I was in China for one week every quarter during 10 years. I made sure my slides were properly translated in Chinese. I went to Chinese restaurants with the team. I’ve read many books about Chinese culture. All of this makes working with another culture easier, as you get a better understanding of it.”
“Team members in a country tend to display common attitudes. You’ll end up realising that a country is predisposed to theoretical fights, and that while employees are focused on proving themselves right, business is blocked. Another country will tend to favour personal relationships and end up coding something depending on what they perceive your personal preferences to be. So knowing you appreciate java, they would code in python with an extra java layer to make you happy. You’ll learn to read between the lines another country gives you, as they’ve shown a propensity to sugarcoat communication. They would present a project as an unbelievable success built by the smartest team on earth even though, really, their project turned out to be a complete failure. You’ll understand that a culture will accept whatever project deadline you give them but will likely deliver only the bare necessities for it to work, while another culture will bluntly turn your deadline down, delivering instead a product much later on, but with all the possible cases properly handled.” Cédric explains: “whatever the culture, all team members are doing their best to make it work. But if you come with your own cultural bias without trying to understand theirs, you’re getting ahead of many problems and much frustration. Spend time with local teams and get to know them if you want to work with them.”
Keeping your initial culture coherent across a rapidly growing engineering team is a challenge. “Talend has had an aggressive culture right from the beginning”, Cédric says. “We were highly ambitious and wanted to have an impact. While in large companies an innovative project that has a 10% change to fail will be a no go, at Talend, if a project had a 10% chance to succeed, we would go for it. There was a 90% to fail, but it was all right. It really was the startup culture of fail fast, learn fast. Being innovative, thinking out of the box, saying things stupid, developing crazy projects… All of this does not come that easily when you have 200 R&D team members within an overall 600 people company.”
“Tackling company culture problems did take part of my time, even though we had people ops working on it with us. Culture can be encoded in seemingly small actions, such as celebrating employee birthdays once a month at the end of the sprint, when all team members are present”, Cédric explains.
Also, as your company grows, so do your clients. “In the beginning we did not have any Q&A. The community was our Q&A. We had milestones every two weeks that the community would test. When there was a release, all its milestones would thus have been already tested by our community. But as big clients got onboard we started having questions about AS400 connections for example. Picture a major international bank group that has its data in AS400 and wants to transfer it to a data warehouse”, Cédric goes on. “They want your connectors to work at all times and performance to be dependable, even when new features are released. You cannot completely rely on the community to test it, what would you do if someone is working on another project and is not available for two months? So you need people to deal with it internally, which comes at a cost.”
Methodology thus not only changes as your team grows but also as your clients grow. “In the beginning we favoured innovation in our releases, even if part of it would not work. Or the main road users could take would work, but not the side roads. With larger clients though, you’d rather wait a little more so that the highway and access road are dealt with properly. You need quality and formalisation.”
“In the beginning we held bug squash parties in which we would invite people in our offices to get feedbacks. Then it became even more structured: we could pay internal consultants. Each month we could take that many consultants from each country. And every 6 months we would take 30 of them in one single place for the “hell week”. They would all be accommodated in one single place with a room open 24/7 and free food and coffee. They had one week to break the product that was about to be released. Having people from all countries is especially interesting because they all come with their own client knowledge and can test a product with different client environments.
Companies in Japan, in the USA or Europe can do very different things with their database. And you cannot release something to large international clients that would work in Germany but create havoc in their US data. So having consultants testing the product with international client environments was very useful. There were games to find the most bugs, to find the most critical bugs. It’s a good example of how processes change over time as your team and company grow, but it can still be encoded with your company culture,” Cédric concludes.
Love this? Share it!