Exporting the DraftKings Engineering Culture
How we built a new hub in Dublin, Ireland while keeping it a part of the DraftKings Engineering community.
In the past 3 years, DraftKings engineering has grown from 150 engineers almost entirely based in our Boston HQ (sitting on the same floor, even!) into a worldwide organization of 1000+ engineers spread across 7 countries. Even before the merger with SBTech, DraftKings Engineering had begun to outgrow Boston and we set our sights on expanding the footprint of the organization to Dublin, Ireland.
Establishing Culture
From the beginning, the mission was clear: instill the culture that has made DraftKings Engineering such a success in Boston, while encouraging the Dublin office to develop its own personality.
Organizational culture is a complicated topic. Culture of any group is multi-faceted and is the result of the values that the organization embodies, the personalities of individuals and teams within that organization, and the habits, norms, and reactions that are on display every day. Like any other quality of our organization, it is something we at DraftKings Engineering constantly seek to improve.
We set out to establish a new office created in the image of our engineering culture, but attempting to create an exact copy of Boston culture was never the goal. The new office is in a different country, with entirely new folks who have entirely different experiences. It reminds me of an episode of Top Chef where masterful cooks start with the same ingredients and produce wildly different dishes. We want to start everyone off with the same ingredients and then be blown away when each office produces something that fits the situation and the unique experience of individuals.
There were a few key decisions that proved to be instrumental in achieving our goal:
- We seeded the office with a couple of engineers who understand software development at DraftKings from both a technical and non-technical perspective.
- We started the new teams off with a business-critical project that they could own end-to-end.
- We found different ways to build strong personal connections between individuals in different offices.
- We trusted our new hires to add their own experiences to the new office culture.
Getting some help
I asked a couple of engineers from the Boston office to move to Dublin and join me from day 1. These folks became a constant resource to new engineers joining DraftKings in Dublin. While seniority and tenure can be important factors in getting work done, we decided to focus more intentionally on engineers that embodied the DraftKings culture. We looked specifically for people who demonstrated bias for action, commitment to customer experience, analytical thinking, and attention to operational excellence in their daily work.
Armed with their experience with the software development process at DraftKings, the engineers from HQ cut through things that would have otherwise caused early frustrations for new hires operating in a different time zone. Questions such as How do we do database deployments? What integration testing patterns do we use? What team handles CRM technology? How do I request access to this developer tool? Have we thought about using this new framework? But as a new hire, nothing beats having someone you can chat with during any working hour and have a conversation.
Picking a project
Project selection for the new office is an extremely important part of establishing the culture. Having focus on a project helps to hire the right talent. It also gives the new office an identity in the minds of everyone in the rest of the organization.
In interviewing candidates for the Dublin engineering team, one of the questions I frequently get is “What am I going to work on?” The line of questioning that follows from the candidates is less about the domain or the technology and more about answering a different question: “How critical is my work to the success of DraftKings?” And that’s a perfectly reasonable question.
Dublin has become a tech hub of Europe, with offices of some of the world’s leading tech companies. I came to understand the candidates’ fears in working in an office remote from HQ: that the “important” work will forever be developed out of the HQ office.
It wasn’t enough to convince candidates that this isn’t how we intended to do things. From the day that the first new engineers arrived in Dublin, the office had a purpose. With input from other engineering leaders and the product management organization, I selected a project that was a strategic win for the company.
The project was critical, but not overly time sensitive. Important, but not urgent. Had we selected a non-critical project, the new teams would have felt disconnected from the company strategy. Had we selected something pressing, we wouldn’t have been able to give the teams a chance to form as a stand-alone unit and we would have risked missing the group’s first ever deadline.
Most important of all, the new office owns something. They develop brand new microservices and APIs, which they design, own, deploy and monitor end-to-end. They are the most knowledgeable engineers at DraftKings about this project and its domain. This helps the team establish ownership and by extension its own identity while maintaining a connection to the culture of HQ. As the office adds engineers, projects, and new capabilities that identity will shift and develop, but it will remain grounded in the origins of its first projects.
Connecting people
No engineering team at DraftKings stands alone. Even with complete ownership of a project and technology, the group of engineers in Dublin will not be successful without making personal connections with engineers in other locations, especially in the Boston HQ.
This applies to all levels of the org. Travis Dunn, our CTO, spent some time in the office early on, meeting our first few hires. After COVID-19 restrictions prevented travel between Boston and Dublin, Travis held AMA-style video chats with the group to foster personal connections and inclusion.
While the first couple of teams were ramping up, we were still in the process of filling some leadership positions in the office. Quite by necessity, I temporarily moved one of the new teams under the remote management of a leader of one of the Boston engineering divisions. This had the amazing side effect of organically introducing Boston engineers to Dublin engineers as the leader helped answer questions by directing Dublin engineers to talk to certain knowledgeable folks in Boston. If I were doing this again, even if the situation did not require it, I would look to match the first leaders in the remote office with leaders in the HQ office for some “pair management” for the first couple of months.
Once the team in Dublin was ready to ship some of their first code, we hit a bit of a wall transferring knowledge for some of the devops technology like environment setup, infrastructure deployment, and CI/CD configuration. Rather than leave the Dublin teams on an island (literally!) to struggle through it, I reached out to our SRE team to have an expert engineer assigned to the group temporarily. This engineer understood the context of the work, attended standups, and participated in tech planning, reducing communication cycle time and building yet another bridge from the Dublin teams to an important group based out of Boston.
In all of these cases, pairing folks from the HQ office with various parts of the new organization in Dublin infused important bits of our existing engineering culture into the new teams without anyone really thinking about it. Early members of the team quickly came to understand the norms and expectations of DraftKings Engineering and could pass it on to new members later on.
Promoting Fresh Perspectives
You can’t spread culture to the new office by forcing teams to think and act the same way teams think and act in the home office. I did not dictate the decisions of the new teams when it came to work management, scrum, and technology. The teams decided those things, both based on their previous experience and based on what they learned about DraftKings Engineering culture by working with the folks in Boston. Some of these decisions panned out, while some of them did not. But in making those decisions, the teams built themselves a more solid foundation.
In one instance, a talented new lead engineer in Dublin had questions as to whether the infrastructure libraries that we typically use for microservice development fit the use case for the new project. This was a perfectly reasonable question to ask. The engineer did some short POC work on his use-case using the out-of-the-box ASP .NET Core WebAPI before ultimately concluding that the internal libraries were the better direction to take. But he discovered some interesting potential paths that we could take with our microservice infrastructure in the future to reduce coupling of our libraries to a specific framework. The engineer learned about DraftKings libraries, the engineer felt good about the path they were taking, and we have a new architecture pattern to explore in the future. That’s a win-win-win!
In another example, based on prior experience of the new teams, there was a strong interest in running more frequent progress demos for the rest of the org in Boston, but also for product and business stakeholders. Historically we had reserved such broad demos for meaningful milestones — meeting feature MVP, demonstrating a new flow end-to-end. But all progress is worth sharing and so the ritual took hold and even spread back to the teams in Boston. The Dublin Engineering group now organizes a weekly showcase of any progress — large and small — made over the previous week. Rather than directing the Dublin teams to the existing rituals, Dublin has contributed a new ritual to the DraftKings Engineering culture.
The influx of fresh perspectives and new ideas combined with the geographic separation of a critical mass of existing engineers has proven to be fertile ground for fresh perspectives. Part of the success of building the unique engineering culture in Dublin has been to encourage that type of thinking rather than a default preference for the status quo of HQ.
Next Up
Launching a new engineering office can be challenging in the best-case scenario. Just about the time our first Dublin hires started working, a worldwide pandemic forced us to shift the way we think about remote offices. In the next article in this series, I’ll talk a bit about adapting the launch of a new office while shifting to fully remote work in the midst of a pandemic.
