We recently hosted Fabien Loupy at TechKnowCon for a great overview of his time working at the Canada-based luxury fashion online retailer SSENSE. Loupy’s story is a bit different from some of the others we’ve featured. He started out as a consultant, moving in-house to take over the role of VP of Technology for a privately held e-retailer. Here are some of the key takeaways from that experience.
Solve the foundational problems
When Loupy first joined SSENSE, there was a halting sense of stop and go to the company, as the engineering team jumped from project to project. This made it difficult to build a thoughtful tech-focused organization.
“When I came in, SSENSE was going through a major rewrite of its system from a monolith to microservices, but it didn’t go very well,” recalled Loupy. “And we were in a period of being project-led, and there was no product team yet. There was a lot of stop-and-go, a lot of projects that felt like the flavor of the month. As a result, the code quality was not great because we were always on a project and then about to move to something else after. There wasn’t a great incentive to maintain the code base in the long run and have good code and comments that would help future engineers working on that code path. There was limited accountability, a feeling that it was going to be someone else’s problem. So we didn’t invest as much in making sure there was proper monitoring, alerting, and so on.
Serve the business today
Even though SSENSE was undertaking a major overhaul, it needed to keep moving forward and evolving, which wasn’t the easiest juggling act.
“We didn’t deliver value in 2016 because we basically spent the year doing a re-write,” said Loupy. “For me, that was definitely not the right approach, because the business continued to exist and have needs and we couldn’t just disappear into a room for a year with our devs. We needed to continue to serve the business and support our rapid growth. And so that was the realization, that we had to stop the sole focus on rewrites. We moved to a microservices architecture, through time, by domain, which was selected based on business needs. We knew it was going to be a journey of many years, and we’re still on that journey.”
Although the technical shift occurred slowly over the course of years, it nonetheless brought quick changes to the company’s daily inner workings. We introduced a Product Management function. A VP of Product and ten new Product Managers were hired, and soon there were intense conversations going on.
“We sat down and said, ‘Ok, what’s the product vision?’”, said Loupy. “‘What does it mean to transform SSENSE into a product-based organization? What are our values, and what are our tenets? What’s our intake process?’ We were focused on a lot of things around organization and processes. We had to figure out how to organize our teams into squads and how to group them to be meaningful. This went on from mid-2017 to mid-2019. But then, at the same time, we had to reestablish credibility. And so I worked with the VP of Product at that time to make sure our roadmap was a blend of technical initiatives and delivering value that the business needed on a short-term basis. We were really focused on providing value. Sometimes that value was a technical component, and sometimes it was doing something scrappy, but we needed to be first on the market. And being a product-based organization was really good for that because we were very rigorous in how we analyzed the opportunities and how we prioritized the efforts of the engineering team.”
Coordinate company growth with career progression
In parallel with setting up the product organization, management realized it needed to do a better job taking care of its engineer’s needs.
“We worked on the career ladder as well, because there was no progression past Technical lead ,” said Loupy. “People would ask, ‘OK, what’s next for me? I’m seven, I’m ten years into my career and there is no progression.’ As we scaled, it became important to define that we now had staff developers, that we had senior staff and principals, and we gave people an understanding that they could progress equally on a technical path as they could on the management path.”
Stay value-driven with how you prioritize
There are no clear-cut guidelines for when to prioritize tech versus features, and Loupy often found himself making critical decisions on where to allocate time and resources.
“We hire super-smart people because I don’t think there’s a definitive framework,” he said. “But there are some principles that are easy, like looking at the value that’s delivered. You expect the conversion rate to go up or you expect the cost per unit in your warehouse to go down. The harder part is technical debt, and you have to make an effort to try to size that up as well in terms of what impact it’s going to have. If some change really creates a technical risk and we’ve proven it through load testing for example, and there’s a disagreement between the director of engineering and the director of product, I’m there to make a decision, and maybe I say that because of the long-term sustainability of our platform, we’re going to prioritize stability this time around.”
Revisit your hiring strategy as your business needs evolve
During the early days of his tenure at SSENSE, Loupy found that his workforce’s high level of attrition was directly linked to his staff having too many generalists.
“There’s a lot of energy that’s lost in the discovery process, in searching for things that people with expertise would have found much faster,” he said. “This was true on both the product and engineering sides. Take our operations domain: we had a lot of really strong PMs, but they really didn’t know operations. We thought they would ramp up and learn on the job, but that takes a long time, and it was sometimes incompatible with the speed at which we were evolving. This created a frustration from the PM, who was not in a position to succeed. There was a high expectation that he or she could not meet because of the lack of expertise. At the same time, the operations business team became frustrated because they had to do a lot of the work on requirements instead of the product team doing it. And the engineering team became frustrated because there was a lot of uncertainty on requirements as they got closer to implementation. Under the leadership of our CTO, we agreed to move to expertise-based hiring. This is harder. It takes time. We had unfilled positions for much longer than we wanted, but we’ve seen a dramatic change as well. It makes a whole difference because we know where we need to go.”
Create deliberate onboarding for increased velocity
In other areas, SSENSE experienced delays because their veteran employees needed to spend too much of their time and energy helping new hires get up to speed.
Recently, we decided to invest in Tech Enablement more because we did see a process of divergence between teams.
– Fabien Loupy | VP of Technology, SSENSE
Loupy added, “we have a core of 20 or 30 people who have been here for some time and understand the system. But then they have to train so many new hires. We don’t have a great, robust onboarding system where we will do a bootcamp for one or two weeks. And so we have seen velocity go down.
Investing in Tech Enablement in 2022 and 2023 will allow us to tackle this issue [velocity]. It will include for example the creation of a robust onboarding bootcamp.
– Fabien Loupy | VP of Technology, SSENSE
Decentralize the budget process to align on purpose
Loupy shared an unconventional view on Tech Enablement. He argued that giving detailed budget visibility and decision-making ability to teams lower down on the org chart empowered them and supported Tech Enablement. In the process, he created a successful arbitrage marketplace where teams could trade with one another, swapping budgets for the prioritization of certain initiatives. Ultimately, this led to the creative and intelligent allocation of resources
Empowering our teams with the budget has been a huge unlock of Tech Enablement.
– Fabien Loupy | VP of Technology, SSENSE
He mentioned, “in the past, I owned the budget, and teams didn’t necessarily have visibility on it, except an aggregate view. The tech team was always seen as the team saying ‘no’ to features because we had limited capacity. With this change, we saw that some of the departments transferred a part of their budget to technology because they saw the potential. One department, for example, said, ‘well, I think if we invest in tech capacity to deliver this new business capability we will generate at least a 3X return in-year which will be beneficial for the department and SSENSE at large’. This changed completely the discussions with our business counterparts. I think it really empowered the team and improved collaboration. It enabled them to be more autonomous, go faster, and really have a sense of purpose that we may not have felt as much in the past where that wasn’t as clear.”
Build vs. Buy: Consider the Trade-offs
SSENSE took a lot of pride after its founding in being a company that built nearly everything in-house; this was a major reason they considered themselves a tech company. As the organization matured, though, it realized it was better and more efficient to buy rather than build in targeted areas.
“Historically, we built everything,” said Loupy. “It came from the CEO’s engineering background and how we have been successful. We built the website, the order management system, the warehouse management system, everything. We were in that culture for a long time, and I think we probably didn’t question ourselves enough until recently. But we ended up building a lot of things that are available on the market that are more feature-rich. Yes, we built it, but sometimes our business counterparts were not happy because there weren’t many features. We’d maybe assign a team of five to continue and expand the product, but it was probably two years away until they had what they would really need for us to be efficient. And so there was a kind of ‘aha moment’ where we decided not to be so dogmatic about building everything.
Sometimes the solution is not super expensive, so we decided to just buy and integrate and save the time and invest it to spend more time in other areas where we can differentiate.
– Fabien Loupy | VP of Technology, SSENSE
It was great to hear and learn from Loupy’s journey. It drove home the point that tech companies need to be nimble and creative as they go about scaling their companies. There are always opportunities to succeed and differentiate, though they need to be carefully scouted, and the battles waged to win them need to be carefully chosen. All in all, the story of SSENSE is a great example of just how much growth and efficiency can be gained from smart Tech Enablement solutions.
