AWS Storage Blog

Tips for effective innovation collaboration from Pinterest and AWS: Part 2

This is the second of a two-part series on how Pinterest and AWS worked together to solve a complex data access problem.

Note: The launch for S3 Access Points aliases on 7/26/2021 makes it easy to use an access point for any application that requires an S3 bucket name.

Researchers from the Kellogg School of Management at Northwestern University and China’s National University of Defense Technology recently released the results of a study that reaffirmed the power of collaborative innovation. The study looked at the research habits of scientists and found that future Nobel Prize winners spent their early years working in larger teams and, on average, published almost double the number of joint papers as other scientists.

“In contrast to the iconic image of lone geniuses making guiding contributions, we find the giants in science in fact show a greater propensity toward teamwork,” said Dashun Wang, Kellogg School of Management at Northwestern University in Evanston, Illinois.

At AWS, we value diverse opinions, and invention through collaboration is a way of life. But when we have the opportunity to take that collaboration to work side-by-side with a customer, well, that is solid gold.

“Collaborating with a customer lets us see up close the problems a customer is trying to solve and how those problems impact their business,” said Doug Youd, AWS Senior Solutions Architect. “But the opportunity is even bigger than that. The challenge one customer faces is probably a challenge that a lot of customers face. So, often when we help solve a problem for one large customer, we learn things that help benefit many customers.”

AWS recently had the opportunity to collaborate on a 22-month project with Pinterest, an innovation leader in creating personalized discovery experiences. Technologists from across AWS joined forces with technologists from across Pinterest to solve a complex problem related to data access control. Pinterest had been looking down the road and anticipated that, as it grew, it would eventually need greater speed, control, and flexibility in controlling developer access to its data lake operated using Amazon S3 and Hadoop. Working together, AWS and Pinterest developed a solution that leveraged Amazon S3 Access Points, an S3 feature that AWS released in December 2019. With AWS support and using S3 features like Access Points, Pinterest then developed Pinterest Fine Grain Access Control (FGAC), which allows Pinterest to grant access to specific data sets by individual company engineers rather than by groups.

(For those who want the more technical explanation: FGAC vends per-user access tokens to Hadoop using AWS STS.)

Pinterest now uses FGAC in a variety of ways, including user features that help make Pinterest more inclusive. With FGAC, Pinterest created a seamless process where creators and businesses can self-identify as an underrepresented group for amplification of their content, while ensuring the data won’t be used for any other purpose, such as advertising or additional targeting.

Dozens of engineers and data scientists from different AWS and Pinterest teams collaborated to go from the initial “We don’t know how to solve this” to “We have a solution that we can use with our most sensitive data.” The project was a huge undertaking that required not only multiple areas of expertise but also an openness to new ideas, a willingness to listen (even to the seemingly wild approaches), and an appreciation for what both companies brought to the table.

Doug from AWS and Keith Regier, an engineering manager at Pinterest, worked together on the FGAC project and put together six tips from their experience of collaborating “across walls:”

1. Clearly define the problem you want to solve and how you will measure success.

Keith: “Once we all agreed—after weeks of debate—that our purpose was to ensure that each end user could access data on their own behalf with their own unique set of permissions, this became our rallying cry. It was a powerful catalyst in our conversations with AWS because we knew what we wanted to achieve.”

Doug: “In the beginning, there were lots of different opinions on how we should approach building a solution, but we weren’t aligned on the problem definition. Once we agreed on the problem, as well as requirements and constraints, we could quickly eliminate options and focus our efforts.”

2. Ask questions, explore “bad” ideas, and be willing to be wrong.

Keith: “I was new to this kind of data problem and didn’t really know the difference between a dumb question and a good one. I was willing to be wrong and ask questions. But no one came into this with a lot of ego, so we were able to have productive brainstorms, where everyone threw ideas on the table.”

Doug: “The bad ideas often turned out not to be so bad. They helped us build models and uncover nuances that we hadn’t explored before. Even ideas that we decided not to pursue helped us define the problem.”

3. Understand the boundaries and constraints on the problem, especially which ones are hard constraints and which ones you can move.

Keith: “One reason this project was successful was that we always looked around corners. We eliminated half a dozen options quickly by understanding the limits, which ones could be raised or worked around.”

Doug: “Everything about the problem was astronomical, so at first, there were lots of vague, ‘hand wavy’ concerns: ‘The platform’s really big’ and ‘We have so many different policies.’ But when we started defining costs and constraints with data, we discovered that the problem wasn’t as intimidating as we’d initially thought.”

4. Accept that you can’t go it alone and understand what each party can bring to the table.

Keith: “We came to the table and said, ‘We, as Pinterest, don’t have enough information on how the AWS services work to craft the right solution.’ It was the little things we gleaned from conversations with AWS—the tiny details—that made a difference. They AWS team often told us something about how a service worked that gave us a whole new set of ideas.”

Doug: “This was an opportunity to walk in the shoes of the customer and see the constraints they’re dealing with, the real world problems. And we had insights based on working with other customers that could help Pinterest eliminate options early and get focused on the right direction. Also, as Pinterest’s account team, our job is to help them solve problems, and we had the flexibility to work on this before it became a funded Pinterest project.”

5. Expect some people to leave the project along the way—let them.

Keith: “Different people supported going in different directions and had different perceptions of risk for each. But we had to pick one approach to pursue. Some people cut ties with the project at that point, but that was okay. The people who stayed with it were the ones committed to solving the problem.”

Doug: “Healthy competition between the two top options sharpened both proposals. Ultimately, we made a data-based decision on the best way to go. Some people weren’t happy with the decision, but to move forward, you have to pick a direction. Once you do that, you energize the project with the people who remain. In this case, that was most of the team.”

6. Have a plan for selling your idea and building support.

Keith: “We came up with just a couple of slides that we could all use that had simple bullet points that were almost like slogans for the project, the two-sentence elevator pitch. This made it easy to introduce new people to the problem we wanted to solve and bring on the people we needed to build the solution.”

Doug: “The process of building support provides valuable feedback. And there are two parts to this. You need to get engineers excited to work on the project, and you need to get leaders to provide funding. To do this, it’s important to create achievable goals that enable you to demonstrate progress. Get off the white board and start building.”

You can learn more about the Pinterest-AWS FGAC collaboration in part 1 of this two-part series.

Wrestling with a tough technical problem? Contact AWS. Our Professional Services team and AWS partners can help.

Sean White

Sean White

Sean White is the Amazon S3 product marketing manager at AWS. He enjoys writing about the innovative ways customers use Amazon S3, launching new features and innovations that that delight customers, and simplifying the complex. He is based in Boston, loves spending time with his wife and two kids, watching sports, and exploring craft breweries.