Building a New Product Hub From Scratch

Problem

A few years ago I joined a company that was expanding rapidly; the business was doing great but it was becoming exceedingly hard to hire new people in Paris where the company had its headquarters. As we considered other markets to expand, opening another office in another country seemed like a reasonable decision. Barcelona stood out as one of the most attractive locations and I was the first to be hired there and tasked with building teams of PMs, designers, engineers and even a data team from scratch.

I was aware that a new hub built from scratch will never have the same level of autonomy as headquarters and that we would encounter many dependencies, budgetary constraints, lack of trust, reduced access to information, etc. In addition, since we started from scratch, we initially had less impact because we had to hire new people, onboard them, and make them familiar with the company’s processes, product(s), context, people, and culture.

On top of that, I had to balance between newly hired teams that were added at a rapid pace and left without enough time to absorb new people and adjust to the ever-present changes. That often became a fertile ground for inter-team conflicts and competition which also demanded my involvement.

Actions taken

I believe that spending as much time in the main office before launching a hub was highly beneficial as I was trying to profoundly understand company values and culture and establish as many personal connections with people as I could. Also, as soon as new hires started to join our hub I would have them spend some time interacting with people from the main office learning about the culture and getting to know people. I was trying to meet as many stakeholders as possible during my stay at headquarters since I knew that I won’t be able to meet any new ones once I start working from the hub. Getting to know them in person would make all the difference -- if I would have to Slack someone it would be so much easier if I have met that person before.

I started small and gave myself some time to make an appreciable impact. All the dependencies and remote work-related impediments wouldn’t allow me to ramp up as quickly as I could if I were based at headquarters. Also, I would rather commit to smaller things with less significant impact, but that would put things in place and instill confidence in new team members. If I would overcommit early on, that could give rise to frustration and disappointment across the team. So, I decided to start small, but make sure that the headquarters were noticing how things were progressing. One project after another and I was able to gain on speed and scope. Taking small steps made our hub team stable and thus faster, and that helped us gain visibility and trust with stakeholders.

I didn’t allow small victories to divert me from staying on the path of being humble. If I would show off too much it would hurt the whole ecosystem and create unnecessary tension between my team and headquarters as we might be perceived as a competition and not a part of the same effort. Oftentimes, people working outside the main office would group together and develop a pack mentality and furthermore, perceive people at headquarters as adversaries. In the tech world, there are always dependencies and this mentality is hurtful to the team and the company. Part of being humble would also include giving credit to the main office teams. Whenever I felt that due to the slow pace or blockers on their side I was unable to complete things on time (or at all), I was trying to be patient and deal with frustration internally.

Lessons learned

• One of the key challenges I faced was how to maintain our autonomy while still being tightly connected to the main office. We would encounter multiple dependencies on a daily basis that would require continual communication and involvement with the headquarters, but when the boundaries are clearly set, your autonomy won’t be jeopardized.
• Remote communication is a whole different ball game compared to in-person communication. This particularly applies to situations when you are tasked to build a team from scratch and when you are yet to establish relationships with key stakeholders. One of the key differences is that you can’t just walk into another person’s office and ask for something. Instead, you need to invest much more time to introduce preliminaries and share context before asking for any action on their part.