Stripe builds economic infrastructure, and we’re designing for a global audience and market. In doing so, we carefully consider our technology and tools, organizational structure, and employee representation. Successful global organizations establish this mindset for different reasons. For some, it’s foundational—their mission, product, and addressable market crosses time zones. Others develop an international customer base, hire remote employees, or begin to open offices abroad to extend their physical presence.

Stripe subscribes to all these definitions—and, in some markets, has been shaped by these choices. For example, Stripe first launched its products in Ireland in 2013. Two years later, we set up a Dublin-based office, which is now home to over 140 Stripes. And last summer, a landing team arrived in Dublin to establish our first engineering hub outside the United States.

We’ve learned that building a global company means building global products—and that those products improve even faster when they’re developed on the ground, closer to customers. In five months, we’ve helped our first customers go live in Estonia, Poland, Greece, Lithuania, and Latvia. We’re building products for Europe, and scoping our entry into the Middle East and Africa.

Scaling an engineering team requires new strategies for hiring engineers in new markets, developing products across time zones, and nurturing a distributed engineering culture. It’s not a sure fix, but we’ve found the best primer for success starts by forming and deploying a great landing team. Here’s what we’ve learned.

How we assembled a landing team

Stripe is not the first company to form landing teams to launch engineering hubs, nor will it be the last. (We’ve done it not only with Dublin, but also Seattle and Singapore.) We studied a few different models, drawing from our own expansion efforts and other companies’ experiences. The main options we considered for Dublin largely fell into a few approaches:

• Hire a local leader. This choice involves recruiting a seasoned engineer—often an engineering leader—already based in the region. It leans heavily on that person’s ability to attract talented developers through her network. It can put a lot of pressure on one person’s ability to switch between developing products and growing a team, all while working from a satellite office as a new employee.
• Deploy an engineering leader from headquarters. In this approach, a company sends an established, trusted leader to build out an engineering team. This leader has company knowledge and know-how, but likely an underdeveloped local network. She faces the same challenges as the local leader: it’s difficult to start building products until early engineers sign on, so hiring and developing products often happen sequentially. This can be frustrating for headquarters because product development is stalled, but also for the hub’s newly hired engineers, who have a hard time initially executing.
• Transfer a team that includes a manager and a few engineers. Instead of seeding the engineering hub with one person, another option is to import a team of people from headquarters. Pairing a manager with developers can help mirror the engineering team and reporting structure at headquarters. Each member of the landing team can develop distinct competencies (e.g. recruiting, onboarding, and product development). This approach requires being thoughtful about how to integrate newly transferred and locally-hired engineers as the team grows.

To launch our Dublin engineering hub, Stripe assembled a core team of four engineers—all of whom were peers. To source the group, our head of engineering David Singleton announced the opportunity to join the landing team at an all-hands meeting. Announcing the news directly to the company brought importance—and transparency—to the formation of the team. He introduced the concept and objective of a landing team: a group of engineers assembled to build an engineering hub and products for a global market.

To join a landing team, there are three objective criteria we considered for engineers:

• You demonstrate results and embody Stripe’s operating principles. Members of the landing team have to be high performers, especially to get work done well with a lean group. They also needed to exemplify  so they can model those standards for a nascent engineering hub.
• You’ve been at Stripe more than a year. Applicants have to be at Stripe for a year, enough time to become familiar with the company’s practices, processes, and priorities.
• You can relocate abroad for one year, ideally two years. By signing up, each member commits to at least one year building out the engineering hub—and ideally two years. Stripe believes in a gradual, supported rollout of a global hub, rather than quickly landing, launching, and leaving. It can take months to build a pipeline of strong engineering candidates; we interviewed ten engineers before making our first hire in Dublin. It all takes time.

After careful thought, we decided to exclude some factors from our selection process. Here are a few qualifications intentionally not part of the criteria—and why:

• You must have a certain level of seniority. An engineer at any level can apply to the landing team. While engineering experience is helpful, performance and tenure—and strong working relationships with colleagues at headquarters—are most valued for spinning up a new engineering hub.
• You must be a specific type of engineer. Some landing teams are composed of engineers who have already worked together and specialize in a company’s core product. Dublin landing team members came from across Stripe—specifically its Applications, Infrastructure, and Payments teams—even though most of its engineering work sits squarely in the Payments organization. This choice brought a steeper technical learning curve to landing team members in the short term, but a wider knowledge of the engineering organization. As the team builds out engineering pillars, the seeds of that expertise are already in-house.
• You must have a proven track record in hiring a team or building culture. Some landing teams might include technical recruiters or engineering human resources business partners (HRBPs) to help build an engineering hub. Each member of the Dublin landing team is an engineer who learned and took on hiring and team-building responsibilities. The landing team often works with the People and Recruiting teams at headquarters, but they must be able to independently source and interview candidates.

The Stripes selected for the Dublin landing team hailed from across the engineering organization: a product engineer on our Subscriptions product, a databases engineer, an engineer from our Payments team, and an engineer who worked on our dashboard infrastructure. We arrived in Dublin in the summer of 2018.

How we’ve deployed and modified our landing team

As a landing team, our mission is to grow Dublin’s engineering team and build better regional products for Europe, the Middle East, and Africa (EMEA). We split our time between those two goals and have identified primary targets: grow the engineering hub tenfold by the end of 2019, and launch more countries and payment methods in EMEA. These goals are not exhaustive but directional, and keep us focused and marching to the right end state: a thriving engineering hub in Europe and better product functionality for users around the world.

We’ve found that the most effective strategy requires being especially thoughtful in three main areas: reporting, division of labor, and team integration.

Reporting

A foundational challenge in most growing, global organizations is how people outside of headquarters—a remote worker, a distributed team, or a satellite office—can stay connected to and plug into the mothership. We’ve found it helpful to move in phases; at first, the landing team’s manager was based out of our San Francisco headquarters, but now we all report to Dublin-based managers. Here’s why:

• Early on, the role of liaison is most critical—and being at headquarters helps. When the landing team arrived in Dublin, our manager was based in our San Francisco headquarters. There he could triage problems and unblock resources on our behalf. If needed, he could solve issues or set expectations in-person with stakeholders. He had full team context having led part of our Payments organization. As a long-time Stripe, he also knew how to navigate the company for our first projects. Fast and direct communication with our San Francisco team is always key, but as we grew and formalized processes, we increasingly needed managers in the same time zone.
• We want the path cleared for homegrown leaders. Most of our landing team will return to headquarters after two years: this is a pattern we’ve seen across companies spinning up new engineering hubs. Our intention from the start is to hire and groom leadership internally. A manager in San Francisco provided us with support and guidance while giving us time to hire or develop locally-based managers; we now have two engineering managers that were hired locally. They feel like they own and can steer our new operation, rather than simply inherit it from a temporary landing team leader.

Division of labor

One of the key advantages to a larger landing team with a two-year runway is how team members can discover local needs together and divide and conquer the work. We started the process organically and found our specialities through meetings where we’d discuss any and every topic, from the tactical to the theoretical. For example, we dedicated time to discussing how to grow the new engineering hub’s culture, or how pull requests could be approved more easily across time zones.

In the early days, it helped that we were all together to list, define, and discuss the full universe of challenges that we faced. After about a month of being in Dublin, we noticed that certain landing team members would gravitate toward key responsibilities. Soon those roles crystalized based on the needs of the growing team and owned by its members. Each of us took point on one of the following responsibilities:

• Spin up new engineers and helps integrate them into Stripe
• Represent the needs of global users, so the products and infrastructure that Stripe builds works for users worldwide
• Champion Stripe’s learning culture, such as through periodic paper reading groups, and tech talks about computer science or how Stripe operates.
• Lead recruiting, from sourcing our candidate pipeline to running and adapting our interview process for our Dublin office

Our team members have each gone in different directions, but in ways that roll up to building better global products and a European engineering hub. We found it best to not be too prescriptive. We observed problems, how they clustered, and volunteered to own them. The four of us don’t convene that often anymore, unless it’s to serve as each other’s sounding board or if new issues arise.

Integration

If the engineering team is being built in an existing office, the first item of business is to integrate the landing team. A practical, but sometimes underrated step is for all the landing team members to arrive at roughly the same time. Timing and logistics challenges on top of a team transition can make it difficult to simultaneously arrive, but it’s worth it.

The landing team started within two weeks of each other. It helped to introduce ourselves and build relationships as a group, rather than as solo engineers trickling in. In the following months, we onboarded engineers both by cohort and in a staggered, one-off way. Soon, team members had varying knowledge about Stripe, our products, and the region.

So we split the team in half. The third batch of Stripes triggered the reorganization. Once we had more cohorts of locally-hired Stripes than relocated Stripes (the landing team), we restructured. We now have two teams: one group works on core markets and the other focuses on expansion. Each contains members from of every starting cohort, including the landing team.

This reorganization after the first few waves of hires has done the most for the integration of our engineering team. We’re now less identified by our early roles or when we joined, and more by our new team identities. We’ve noticed how few people refer to “the landing team” by name; it can’t happen more than once a week now. In this case, success meant shedding the landing team identity and adopting one as a team building out an engineering hub.

Landing teams as evaporating teams

Recently we’ve had a new Stripe move to Dublin. He’s not on rotation, but has relocated permanently to the office to start a new branch of a team called Developer Productivity. Within six months, we’ll have an engineering pillar orthogonal to our landing team and its mission, but growing Stripe’s engineering capability abroad. We will continue growing in Dublin this year.

This marks a new phase for Dublin’s engineering team—a sign of a scaling, more complex technical operation, and the movement from team to engineering hub. As for the landing team (when we’re still called that), we still debate when our job is complete. Every once in a while a member will pose to the group: “What are we actually doing?” Each time that’s asked it’s been an inflection point, a signal that we’ve grown and integrated the team a bit more or have made better global products—and that we need to step back to assess what’s next.

We’ve decided that the ultimate mark of success will be how the office continues once we’ve left. If we’ve dissolved into the broader engineering team, and then can move away without hiccups, we’ll have done our job. We have until 2020 to get there.

If you’d like to help us found and build Stripe Engineering in Dublin, reach out to Peter, J, Louis or me. Join us! You can apply to our open roles here.