A Chapter at DraftKings

The construction of development teams has been a long-discussed topic in the software world. The most common two schemes include full-stack teams and platform teams. Most companies that I’ve seen tend to pick one style and stick with it. Rarely do you see a company with both platform and product teams. In the end, there are tradeoffs between those two team styles but here at DraftKings, we’ve managed to find a middle ground that we call Chapters, which helps us achieve the best of both worlds.

A Chapter is a platform-focused, overarching group whose goals are to resolve tech debt and improve the technology. At DraftKings, we have both platform and full-stack teams for product development and members of these teams also contribute to their platform’s Chapter.

To better understand how Chapters fit in with our developer life, I need to talk about the benefits and tradeoffs of full stack and platform teams.

Full Stack Teams

My first major project at DraftKings was on a full stack team as the only Android developer. We were making a new version of our landing page. Our team was small; Backend, Android and iOS each only had one engineer, but our integration was flawless. Designs were settled, the behavior was hashed, contracts were made and we even finished some stretch goals like video capability. Before we could finish and release this project, business priorities changed and the team had to move on from this project, leaving it uncompleted. This was about two years ago now, but recently it’s been picked up again, and after being asked to review the work to handoff, I realized the code quality is honestly not where it should be. Classes could be better organized, more unit tests and a better feature flag system are easy standouts. Being the only Android engineer, there wasn’t any critique on how I structured the code or managed my tests. Other Android engineers in the company reviewed the work, but since they weren’t working in the same space and lacked the context of the product goals, it was a less thorough check.

While integration speed is very attractive to a product-driven organization full-stack teams do come with their pros and cons.

Benefits

• Fast product development
• Good cross-platform communication
• Faster iterations

Trade-Offs

• Harder to train new talent
• Siloed knowledge
• Can have lower quality code

To keep teams agile, teams only consist of a handful of members. This means that since each platform may only have a few engineers, they all must be very experienced. Assigning a new engineer or training a new engineer in this environment can often be overwhelming with less attention given to developer growth.

This approach also silos information. With multiple full-stack teams, each team primarily supports a specific feature set. This creates an ecosystem where engineers have incredibly deep knowledge in specific parts of the application and very minimal in others.

Platform Teams

At a previous company, I remember joining a platform team whose project was to design a UI interface for a hardware product. During my time on that team, I felt many of the pains of working on siloed platforms. The UI, firmware, communication protocol, and hardware were all separate teams with their own schedules and milestones. There was almost no communication between each of these teams and integration was always a nightmare. I remember a meltdown where the firmware boards were getting too hot and hardware had to redesign the chassis, but at the same time firmware was using a different version of the communication protocol from the UI team, both teams using different outdated versions. Worst of all, is that a handful of people knew only parts of the integration, and that knowledge was not shared. Needless to say, we never hit a deadline.

From this experience, I’ve concluded platform teams have several benefits as well as some drawbacks.

Benefits

• Great environment for training new engineers
• More refined best practices
• More willing to experiment with different libraries

Trade-Offs

• Integration can be a struggle
• Easily blocked by other platform teams
• Slower development

Platform teams are susceptible to high pace changes. Since platform teams often don’t have the same closeness with other platform teams, integration can be a struggle. For instance, API contracts might get updated and frontend teams might be unaware, or the frequency with which the API gets called might not get communicated and load problems could occur. Products and features usually get delivered slower as well, since these teams get blocked more easily by other platform teams.

I draw these benefits and tradeoffs from my own experience at DraftKings. When I first started, I remember struggling with our tech stack and constantly walking across the office to speak with another Android engineer from a different team. It took a long time until I felt comfortable in our codebase. Along the way, we found that the conversations we had were mutually beneficial and created a round table that eventually evolved into a regular monthly meeting where we presented, shared, and talked about future technologies. One of the managers found out what we were up to and turned it into what we have today as our Chapters programs.

Chapters

A Chapter is an overarching platform group that goes beyond the product-focused platform or full-stack teams. Its main goals are to tackle technology-based problems and technical debt. Engineers from all product-driven teams participate in their respective discipline’s Chapter to advance DraftKings technology stacks.

The members of the Chapter meet once a sprint to discuss what our own teams are doing, where we are in our Chapter initiatives, lessons learned, tools created, and more. In addition, we also hold our own retrospective meetings and have our own project evaluation/proposal process. As a Chapter, we’ve adopted Kotlin, Google Room, preparing for Jetpack Compose, started a migration to Retrofit, and more. Through the channel of Chapters, we have established that all new code is written in Kotlin, defined coding standards, shared a growing set of tools, and solidified our codebase’s architecture.

One of our first Chapters initiatives was a Storybook project. We were trying to develop a design language across all the products. This means preset fonts, preset color palette, common component patterns, etc. The idea is that with preset styling and reusable components, we could develop views faster, make them more reusable, improve quality and cohesion across the app. Since this was an internally driven initiative, the project was brought to the Android and iOS Chapters. After understanding the problem, both Chapters divided the work across its members to tackle this challenge.

There were three main parts to this project.

1. Align the current use of colors, font sizes, styles in the current app to a single style guide.
2. Develop a new way to create views only using basic types. This would remove the need for complex or use-case-specific data types when building views, making them inflatable anywhere with basic dummy data.
3. Create an activity that can display these views that’s easy to use as a lookup.

On the Daily Fantasy Sports product, we have 3 teams with mobile developers, so we split up the work using these three categories. Chapter work was included in the individual team’s sprints (and worked on over the course of many sprints) and when all work was finished, the Chapters had created a view glossary for our application. All future reusable views are now created with our new best practices and added to the storybook’s view glossary where our designers and developers can easily explore what already exists within the app. This has become an actively used tool to develop against and share completed work with design for their approval.

Now that this tool is more widely used, it is also maintained and updated with new features, also by the Chapter. The next things to build into this storybook are:

• A standalone app just for the storybook activities/fragments
• Optimize how we scale with more components and views
• Add another storybook activity for drawables and images
• Some basic navigation between storybook pages

Engineer Growth

My time leading DK’s Android Chapter has given me a lot of perspective. I’ve found it valuable in learning how to delegate, as well as how to guide a group towards my vision. It’s also forced me to build better time management habits and try to grow engineers outside my own team. One of my first challenges was defining a process to inject technical initiatives into each teams’ work pipeline. After theorizing a process, I decided to try it and give some junior engineers a chance at technical planning. They created a One Pager, Tech Plan, and did a formal Tech Plan Review to add Airbnb’s Epoxy Library to our app. Since then this has been a great avenue for providing junior engineers an opportunity to expand their responsibilities and gain valuable experience in a safe space with lots of safety nets and manageable stakes.

Seeing Chapters as another opportunity to grow our peers, we’ve also decided to make chapter leadership a rotating role with a 6 to 9-month cadence. The idea is that while on a given day-to-day team, leadership may not change often but Chapters can be a place to grow engineers and allow opportunities for them to obtain leadership and managerial experience.

For DraftKings, Chapters is a great solution for prioritizing technology-based initiatives and stimulating engineer growth. It allows us to keep using platform-focused and full-stack teams as needed without having to bear the full burden of the downsides of each. For us, constantly growing and changing to fit the needs of our engineering teams is a priority and Chapters is one of the ways we can do this.