How Ramp’s data team uses collaboration to make a huge impact
Aug 14, 2023
How do you foster better collaboration between your analytics engineering, data science, and software engineering teams? It’s a hard question without a one-size-fits-all answer. What works today might not work tomorrow as a company grows.
Recently, we invited Ramp to the Analytics Engineering podcast to tell us how they do it. Ramp is a corporate credit card company that couples point-of-sale transactions with unified expense reporting. The startup, founded in just 2019, saw its transaction volumes double last year, helping drive it to a $8 billion market valuation.
While many companies talk of their Engineering, Product and Design (EPD) teams, Ramp has adopted what it calls PEDD—Product, Engineering, Design, and Data. Given how data-centric the company is, it makes sense to make data an equal player at the table.
A part of Ramp’s success is its marketing message. Pitching itself as “the company-friendly corporate card,” Ramp’s platform supports automated receipt collection and expense filing. The product’s ease of use appeals to both company executives and employees.
But a part of their success can also be attributed to that engineering culture. Ian Macomber, Ramp’s head of analytics engineering & data science, and Data Platform Staff Software Engineer Ryan Delgado joined the podcast to discuss what’s driving the company’s growth.
Listen & subscribe from:
How Ramp structures its product pods for success
Ramp supports its products through a pod team structure. The accounting product team has a product manager, tech lead, frontend and backend engineer, analytics engineer, and a data scientist.
Furthermore, each team owns its own product roadmap. Since each team needs to know a lot about both its own engineering stack and its specific problem domain, they’re in the best position to drive feature decisions.
The team considers data at every step: Ramp can ship more features, more quickly, thanks to the “compounding context” of a tight-knit team working on the same goals day in and day out. Ramp doesn’t run into situations where marketing suddenly asks for metrics or measurements that don’t exist. Everyone is in the room for those discussions from the start, as the team is building the product.
Evolving the platform in a pod structure
But how do you build shared platform functionality in such a setting? Delgado said that Ramp first vets out functionality as part of the product before refactoring it into a platform capability.
For example, Ramp initially embedded its Payments team as part of the Bill Pay team. Once they launched Bill Pay successfully, they worked on turning Payments into a more generalized capability.
This approach is par for the course at Ramp. The company doesn’t build “platform” first. Rather, it builds out the feature’s first use case in production. Then, it builds out the infrastructure—observability, CI/CD pipelines, etc.—to support it going forward.
Delgado, who works on the Platform team, said he doesn’t think about “building a platform.” Rather, his team thinks about how to solve problems such as detecting credit card fraud at first swipe, or scoring how likely a Web site visit will convert to a new customer. The platform evolves from that thinking.
The trade-offs of a pod structure
Are there any downsides to the pod structure? Macomber acknowledged there are trade-offs.
One issue Ramp employees face is that other teams don’t always have a full context of what else is happening at the company. That can lead employees to feel unrecognized when they make key decisions that may be invisible outside of the team. Macomber identified providing more cross-group context as the company grows as one of Ramp’s key challenges.
Moving quickly by letting others in
Being agile and moving quickly sometimes means questioning your assumptions. For instance, Macomber said he originally guarded the company’s SQL and Python code base, limiting contributions to core engineering teams.
“But business logic always finds a way,” he said. Employees developed one-off Excel spreadsheets and Jupyter notebooks to address gaps in the internal toolset. Some of these became critical to running the business.
It proved impossible to hunt down every island of “Shadow IT” as it surfaced and platform-ify it. So instead, Ramp set down written standards for software engineering and opened up its code base for contributions. Potential contributors included employees in org chart-aligned teams, plus those who’d shown “entrepreneurial thinking” in their use of tools like Looker and Retool.
Ramp also takes an agile approach to solving complex problems that stretch the boundaries of its existing systems. Delgado gave an example of Ramp’s agile thinking as it relates to reports.
For some use cases, the “24-hour data cycle”—dbt pulling data into Snowflake with reports generated from Looker—didn’t cut it. Ramp needed to build certain production reports in real-time.
To enable this, Ramp created a read-only replica of its Postgres production database that analysts could access using Redash. Another tool logs what the analysts are doing in Redash and helps mask Personally Identifiable Information (PII) in flight before it is presented to the analyst. This enables access to sensitive data while remaining compliant with data regulations and industry best practices.
Ramp also regularly decides whether to build new functionality or rely on vendors to supply it. This “build vs. buy” decision comes down to two factors:
- Do we want to maintain this code in perpetuity? Macomber takes the view that “code isn’t an asset, it’s a liability.” This means that Ramp ends up looking to vendors for most of its undifferentiated heavy lifting. For example, the company uses Fivetran to bring Google Analytics data into Snowflake rather than writing that code itself.
- Does a vendor who can deliver the functionality that Ramp needs even exist? In some cases, a vendor solution isn’t mature enough or doesn’t have all the features that Ramp needs. Or, sometimes, the solutions available are just too buggy.
Growing impact as a data team
Ramp has released some amazing features with its approach to data. Its latest, Ramp Intelligence, uses generative AI models such as Chat-GPT4 and other large language models to provide pricing and contract assistance to its customers.
Ramp Intelligence’s contract negotiation feature analyzes millions of contracts and purchases for software licenses. It can then tell Ramp’s customers whether their current contracts are at or over average market value. It even determines which may be most ripe for negotiation based on observed price variability. (Pro tip: Don’t bother trying to negotiate your Figma or Slack contracts.)
How does a data team grow their impact and ship products like this? Macomber encourages data engineers and teams to think big; 10 years ago, the worst thing a data professional could do was put a wrong number in a presentation. Today, they could break a critical production pipeline. The scope of a data engineer’s work is bigger—and so are the risks.
Macomber said data engineers should focus on both upstream and downstream opportunities. Upstream opportunities mean producing production-grade data the company can leverage in machine learning models. Downstream opportunities mean identifying where senior leadership is focused—and proactively offering solutions to the problems that keep them up at night.
Macomber also encourages teams to think about their “constraints of tomorrow,” not just the constraints they have today. He recalled his time at Drizly, an alcohol delivery startup, as a lesson learned in thinking ahead.
Initially, the company focused on demand generation. It didn’t capture metrics around, for example, how many deliveries a driver could average per hour. When the pandemic hit and demand skyrocketed, it had to scramble to put these critical measurements in place.
dbt as part of the prototyping process
A new feature with a huge impact can start with a small experiment. And at Ramp, dbt is a key part of that journey. Ramp uses a combination of dbt and Materialize to prototype new features.
As one example, Ramp calculated two metrics for internal reporting: the amount in a company’s account balance and the amount of payment delinquencies it had outstanding. These data points quickly became important to multiple teams inside Ramp. For example, a sudden change in a company’s account balance is a warning indicator of fraud.
As a result, these metrics eventually graduated from dbt and Looker to dbt and Materialize. Finally, they became part of Ramp’s core transactional databases and graduated out of the data team altogether.
There’s no one right way to structure product teams or integrate data engineers into product teams. But Ramp has found a pattern that works for its business model, one aided by excellent execution. Even companies that aren’t as data-intensive as Ramp can pluck a lesson or two from how the credit card company weaves data inextricably through its evolving platform.
Last modified on: Jun 03, 2024
Set your organization up for success. Read the business case guide to accelerate time to value with dbt Cloud.