Building the AWS Partnership from the Other Side of the Table

I've been part of a team my whole life, from my family to sports to school and every job since. The best moments always came from a group of people pulling in the same direction, each bringing something the others didn't have. It's no accident that I see partnerships as central to any winning strategy. The best ones work like the best teams: shared goals, clear roles, and trust that each side will deliver.

I spent five years at AWS as a Partner Solutions Manager, and that time gave me the insight to build a winning partner strategy from the other side of the table. I saw what separated the partners who built real co-sell motions from the ones who never got traction. The winners earned trust with customer proof, worked with AWS field teams instead of around them, and obsessed over problems AWS customers actually had.

I then spent two years leading global partnerships across AWS and Snowflake at another ISV, where I put those lessons into practice. When I started thinking about what's next, I didn't want to run someone else's playbook. I wanted to build one, and groundcover gave me that chance as Head of AWS Partnerships.

The Product and the Partnership

What really hooked me is how naturally the product fits the AWS partnership. The best partnerships create value for everyone involved: solving real problems for customers, driving growth for the partner, and giving cloud teams a compelling solution to bring into every account. That's exactly what I see here.

groundcover is built on eBPF, which lets us collect telemetry at the Linux kernel level instead of inside application code. Three things make it work:

Zero-Code Instrumentation: One lightweight sensor per node sees traces, logs, metrics, and network activity for every workload running on it. There are no SDKs to install, no code changes, and no redeployments. Coverage that used to take months of instrumentation across teams and languages is there on day one, and nothing goes dark because a team skipped a library.

Bring Your Own Cloud (BYOC) Architecture: Our BYOC architecture puts the data plane inside the customer's own AWS account. Telemetry is processed and stored there, on the compute and storage the customer already buys from AWS. Data never leaves their environment, which simplifies governance and compliance while removing the cost of shipping telemetry out to a third-party vendor.

Built for AWS Customers & Sellers: Because the data plane runs in the customer's AWS account, that infrastructure spend counts as AWS usage and can help draw down their Enterprise Discount Program (EDP) or Preferred Pricing Agreement (PPA) commitments. That's a win for AWS customers and field teams alike. When groundcover helps customers win, the AWS seller wins too.

That combination matters more every quarter because AI is changing the shape of the workload. Agents, LLM calls, and the services around them generate far more logs, traces, and metrics than the applications that came before, and the volume is growing exponentially.

Traditional observability pricing charges by data ingested or by host plus add-on features, so the bill grows with the data. Teams respond by sampling and dropping telemetry, which means they lose visibility at the moment they need it most. The math no longer works.

groundcover prices per node, so cost follows infrastructure footprint with no markup instead of data volume. Teams keep full-fidelity data, and the spend stays in their AWS account, where it grows with their environment. We saw this play out with BigBasket, India’s largest online grocery platform. Running on AWS and Kubernetes, their engineering team previously had to forgo distributed tracing and omit test environments just to keep volume-based APM bills under control. By switching to groundcover, BigBasket cut observability costs in half while finally expanding full coverage across the entire stack.

In short, with eBPF capturing the data and BYOC keeping it in their own AWS accounts, they get full visibility without the cost.

Why This Team

This is my first true startup experience, and I could not be having more fun. After years at larger, more established companies, the nimbleness is a breath of fresh air. The pace of technology, especially around AI, means the ground shifts every few weeks, and a small team can respond to that in a way a big one rarely can. I came in wanting to move fast, and every day here gives me a reason to.

The people are what made this feel like the right call. At groundcover, engineers, sellers, and marketers work on the same problem together. Nobody waits for a handoff or a perfect plan. People say what's broken, propose a fix, and ship it. That's rare at any company, and rarer still at one taking on incumbents with far bigger budgets.

That brings me back to where I started. Every team I've been part of worked because each person owned their piece and trusted the others to own theirs. My job is to make that real with AWS: clear owners, shared customer wins, and a motion that field sellers want to bring into their accounts because it helps them hit their numbers.

Getting Ready for re:Invent

One quarter in, we're already moving fast on the AWS side, and re:Invent is the proof point. It's a huge investment for groundcover, not only in the team we're sending, but in the sessions, our booth presence, and the customer and partner activities we're lining up around the week. We're treating it as a chance to show AWS field teams, partners, and customers what this partnership looks like in practice.

We're building toward it with real momentum. We have two AWS competency submissions pending and a third right around the corner. And we're officially listed as a Kiro power for observability, which puts groundcover directly in the workflow of developers building on AWS.

If you're an AWS seller, a partner manager, or an engineering leader tired of watching observability costs climb, I'd love to connect. Drop me a message directly on LinkedIn or come find us in Las Vegas, where you can book time with our team at booth #1852 on our re:Invent page.

The product and the partnership are already working. re:Invent is where we show AWS, our partners, and our customers what comes next.