This is an AMA recap from On Deck Data Science.

‍Florent Silve is the VP of Data Science and Engineering at Hotel Engine. Florent has built DS and ML teams from scratch across a broad set of industries in both B2B and Consumer, including software, travel, hospitality, and the data space. For the past 7 years, he has focused on building data and machine learning infrastructure, products, and services at high-growth technology startups.

‍

‍

You’re on your 4th go building Data teams from scratch - tell us about your approach this time around?

Great question! My approach has definitely evolved since the first time around.

Here are a couple of thoughts.

• Unless your company is building a data product, DS & analytics is kicked off at some point post product. Timing for building the team and the capabilities varies widely in my experience, and the context in which you land therefore varies quite a bit (whether it is context regarding the stage of the company, what is important to the business, what is expected or not expected from data, the level of data literacy, buy in from execs, etc…)
• This time around I have definitely been much more structured about assessing that context, analyzing the challenges to solve and the opportunities for data to add value before laying out a roadmap and defining what to build and whom to hire
• I have also been much more deliberate about the timing and sequence of key endeavors.

Before I even joined the company I spent 2 days with people from across the org to:

• Understand the key areas of Hotel Engine’s business and the teams’ data and analytics needs and potential bottlenecks;
• Map the current state of the data infrastructure, data assets & schemas, data flows, and analytics workflows and deliverables;
• Identify some key areas of improvements with high ROI for the business and define the scope of an associated engagement

And based on this I put a tentative roadmap - which actually 2 years down the line realize that we pretty much tackled end to end.

Even if you join at a point when the CEO or whomever is in charge has pretty set ideas about what data should and shouldn’t be, I would definitely recommend taking time to go through that exercise and be very crisp about the mission, goals, and key 9-12 month priorities for your data org.

‍

Do you perceive significant differences in the DS team building depending on whether the business is B2B or B2C? Would you organize a team in B2B more as a consultancy?

I think it may be more a function of what business model the company has and what matters for success. To the extent that the types of challenges are the same, I would not think that the organization should be any different.

If the company is building a product that is aiming to scale, whether the end users are individuals or companies does not necessarily matter in terms of core impact the team can have. For sure, whether you build software, hardware, or provide services, whether you are in a high transaction industry or low data volume, etc… matters a lot more.

If your customer base is smaller, there are definitely limits to what experimentations you can run and how much you would invest in it.

At Hotel Engine, we had a different set of challenges for experimentation. We are both B2B and B2C at the same time, with potentially a large number of users within a single business account and we definitely had to think hard about our approach to experimentation depending on the features. 

Should we randomize at the account level or user level? Is it OK to show different variations to users in the same account, etc…

‍

How important is your existing network in scaling a DS team from 1 to 5 or 10? 

Definitely helps, especially for the first hires. 

If your company is mid- to late-stage, you may get recruiting resources to help you source talent, otherwise you will likely be on your own. If you can cut down on the effort by hiring people you have worked with already, or who have been recommended  by people you have worked with, this definitely will shorten your time to output and impact, and will drastically reduce the risk of getting it wrong - not only from a technical but most importantly from a culture perspective.

Having said that, it is not necessary, as long as you are pretty clear on who you need to hire at which stage.

‍

How much do you value product and business sense in your early hires? 

This is incredibly important. Your first couple of hires will be the face of your team, irrespective of their seniority, and will set the stage about how data is perceived throughout the organization. 

They will handle stakeholder management and interactions, and even if very technical, will be key in building credibility and trust for your org. Having a strong understanding of the product, business and them being able to articulate as well as you would expect yourself to do it, the value of data for the business shouldn’t be underestimated.

Communication skills are also important. Think about every hire, especially the first few, as a way to give you more leverage and be able to quickly scale despite not having many people.

‍

What frameworks do you use to think about when and who to hire? 

At Hotel Engine, we initially built a centralized, non-specialized team, and therefore needed to hire a few people who could deliver on the key pillars/capabilities of the team. This informed the type of profiles we hired first. 

For the most part, full-stack jack of all trades, who could be setting up the data and BI infra, work as data engineers, but also do analytics across business and product areas. Eventually, as we scaled the team and expanded on our roadmap we started building the team alongside key product and business verticals, targeting people who could be more specialized, both in terms of their key technical focus (DE, DS, Analytics, ML, etc..) but also areas they would focus on (different business / product verticals we have)

In terms of the actual hiring plan, it has been pretty much driven by our cross-functional annual & quarterly plan, with some hires budgeted for key ongoing data capabilities, and some budgeted for us to deliver on new business/product goals.

‍

Do you often see Data Scientists moving out into other either more specialized roles or different disciplines (product)? 

Some, yes, in particular on the product side. There are very few data PMs or TPMs with a strong prior experience in a technical data science/analytics role, and these roles are key if you are building internal or external data/ML products. This is definitely a great transition for someone who may want to move from an IC role as a data scientist.

Still seeing many more making a transition to DS though :-)

‍

How would you recommend DS leaders ensure they’re delivering impact that’s aligned to business priorities? 

Spend time planning cross-functionally with key stakeholders, and not in isolation.

Be mindful about long-term impact (what I call ‘big rocks’ or ’step functions), i.e. key products/projects that can significantly change the trajectory of the company, but also about the short to medium term wins that can influence the business TODAY as opposed to in 9 months if the project is successful.

Find the balance between these big rocks, shorter term impact and supporting the business.

I have seen many companies/teams/leaders in data being either totally reactive and acting as an analytics support team to the rest of the business or at the other extreme spending 9 months trying to build a fully automated ML-based service without carrying about gradually having impact and building trust.

In my experience, these 2 extremes rarely end very well…

‍

If your team is in the totally reactive / analytics support team regime, do you have tips for getting out of that regime and moving the team towards the direction of having the buy-in to build for the long term?

That’s where I think planning is super important.

• Align on what the goals/mandate of data should be at the company
• Showcase, based on the value you delivered for these specific requests, that there could be a more systematic, planned approach for data to deliver value
• Provide detailed recommendations of what that could look like and how this would translate into an ROI for the company.

Easier said that done for sure, but this short term impact is probably your best leverage and translating this into what’s next could give you an avenue to argue for the long term

‍

How do you weigh the value of short term wins vs long term innovation in DS teams? 

Alluded to that a bit in my earlier answer, but by being very structured about our planning and prioritization.

We have quarterly planning, mostly to plan for the big rocks I was mentioning before and define our team’s OKRs. On a monthly basis we review progress to ensure we are on track. We have weekly sprints to plan the work and milestones for these big rocks but also handle shorter term asks/fires and small projects, and make the required arbitrages - still keeping in mind that we both need to deliver short term impact yet make progress on our long term goals.

And then we have daily stand ups.

This structure, and rigor around planning and execution are the main ingredients on my team to weight short term wins and long term innovation.

‍

How have you navigated your career path to this point? Are you working towards a longer term outcome or sort of experimenting in steps? 

Great question! There have definitely been junctures when I have made conscious career moves. 

I was trained as an engineer and economist, worked in finance consulting and investment banking, and eventually moved to data. Since though, the path has been driven mostly by opportunities, and less by a fully planned out journey! I think I would need a full hour just to talk about that :)

My main recommendation on this would be to be mindful of not over-indexing on maybe the wrong things (such as title and comp) when making a move. 

Traction of the company, potential for data to have an impact and be supported, potential for growth and upward mobility is probably way more important, especially in roles in high demand, than optimizing purely for comp

‍

* * *

Learn more about On Deck Data Science here.