Increase your slope

While it is appealing to try and learn a bit of everything, as a new grad, it is simply impossible to do that effectively — chances are you’ll just end up being mediocre at it all.

Typically, your first area of expertise will be wherever your first project at Stripe takes you. You probably won’t have too much of a say in what it is, but pretty much every domain has interesting and difficult problems, and the goal is to become the point person on your team and within Stripe for that one thing.

My spin-up project was to revamp the charts on the homepage of the Stripe Dashboard. I didn’t find the problem particularly interesting, but it turns out charts are really hard, and after 3–4 months of working on them, I had become our team’s mini-expert. Throughout the next year, being the mini-expert meant that even as a new grad, I could quickly drive the mitigation of chart-related incidents, independently execute on dozens of run tickets, and weigh in on product/design decisions. A year and a half later, I’m on a completely different team at Stripe, but my knowledge of charts turns out to still be very relevant.

The natural question then becomes, “How do you become an expert?”

When you’re initially spinning up, there isn’t really a shortcut around first “just doing the work.” It isn’t glamorous, but learning how to reliably execute tasks that are handed to you is the unavoidable first step to becoming an expert. Everything is downstream of first building strong technical foundations. However, as you’re working through problems, be incredibly curious. A few ways of doing this:

This doesn’t just mean reading the Trailhead docs explaining the system architecture. This also means finding the product brief that originally explained the need for the feature you’re building, or the UXR that justified it. Having more context is always useful. Decide which docs are important to read thoroughly and which you can just chat about with your favorite LLM.

No one on your team knows everything. Build a “map” of expertise — figure out who is an expert in the different areas of your team, and then go talk to the people that will know the most about your area. Given the cross-cutting nature of building software, this may often extend to talking to people beyond your team (e.g. if you’re building on another team’s abstractions).

You’re allowed to ask silly questions, and people are generally happy to help — most new grads ask too little, not too much. Before you reach out, be ready to explain what you’ve tried, why it didn’t work, and what your hunch is. Even if your hunch is wrong, you’ve started a conversation amongst peers instead of blindly asking for help, and it’s going to be a lot more fun and educational for both of you.

LLMs can answer most of the what questions — what this function does, what this error means. Save people for the why: why the system was built this way, what’s been tried before, whether you’re approaching the problem the right way at all. When someone helps you, ask how they got to the answer. What made them check that dashboard first? How did they rule out the other possible causes? Experienced engineers make a lot of decisions that seem obvious to them, and you’re trying to osmose their intuition and experience.

I’m not sure it’s possible to end up on a team at Stripe that has an un-dogfoodable product. If you work on a product team, create a little dogfooding Stripe account or use whatever testing accounts your team has. If you work on an internal/infra team, use the tools you’re building! Dogfooding is the easiest way to actually understand your product and your users. You want to understand their use cases, feel their pain, and also recognize the moments of joy that you’re trying to create more of.

Stripes love metrics. We have endless OKRs and Hubble dashboards. If there is a key metric in your area of expertise (latency, usage, user satisfaction, …), you should know about it. You should know how what you’re working on ties into these broader Stripe goals and align the decisions you make with the bigger picture.

Hubble is also an excellent proxy for understanding how users are using your product (and if it’s not, then you should encourage your team to build observability). When I was working on the home charts, peeking into various Hubble datasets helped reveal the strong “default dominance” of our users (almost no one changes their default settings), which guided how we prioritized features on the project and continues to be a key input into how I think about building products today.

AI can both accelerate and hamper your ability to become an expert. It is incredible at retrieving and synthesizing information and, of course, at writing code, and it’s only going to get better. It’s very tempting to offload your critical thinking to it because it feels faster. That’s a recipe for short-term gains and long-term mediocrity — you end up as a meat proxy for the model.

A few habits that can help as you’re spinning up:

Fundamentally, ownership is about caring.

To have a high sense of ownership is to understand and empathize with the users you’re serving, feel responsible for the software you’re delivering, and think about the long-term consequences of decisions. Honestly, pretty much all our operating principles are derivative of taking ownership.

It isn’t always easy to get ownership as a new grad. Part of the way you get it is by demonstrating expertise (see the previous section!), but you can take ownership much sooner than that. Just as you start with a small sphere of expertise, you can start by owning small problems — the things that frustrate you and that you can fix independently: the bug you spot, the legacy testing library your team is still using, the broken Hubble dashboard, the quality-of-life improvement that should obviously exist. By fixing each one, you develop your own bar for quality and ensure the systems around you meet it.

Sometimes the thing you want to fix needs someone’s permission. It used to be that you’d write a proposal, get buy-in, then take a few weeks to build it. For many of the things you come across now, if you have conviction, then you can just spin up the Orbit session, build the thing in a dev environment in an afternoon, and then demo it to the relevant stakeholder. A small prototype makes the conversation concrete and the proposal more compelling.

While you start out focusing on your area of expertise, you should remember that you have (or will have) literal ownership in all of Stripe and should operate accordingly. If the problem you find requires you to change another team’s systems, that isn’t a sign to wash your hands of it. Propose the change, collaborate with that team, and ensure the impact is delivered. The old “edit the company” operating principle remains extremely relevant.

It is tempting to see projects as shiny new toys that you play with before moving onto the next big thing. That's just not how software development works. Of course, almost all software inevitably gets deprecated and deleted, but until then, you continue to own it. It's been five months since I've swapped teams within Stripe, but still I remain in all of my old team's Slack channels (except the private ones they kicked me out of). I continue to follow what's going on, and try to contribute my expertise wherever I can (especially incidents). Another new grad I spoke to even asked their manager if they could go back and iterate more on their spin-up project because they cared so deeply about making it better.

Ownership is also about owning your mistakes (which will inevitably happen if you do anything meaningful and difficult). In 2025, I caused 0 significant incidents. In the first half of 2026, I caused 4 S3+ incidents. That wasn’t because I got worse at my job (I hope). I was just shipping faster and working on more important things.

When users reported these issues, I recognized they were caused by my changes, spun up the incidents, drove the mitigations, and owned the remediations. Stripe has a blameless culture, but I still held myself accountable (honestly, I was disappointed in myself). I reflected with my manager on what we could have done better and wrote about it in my mid-year self-review. I’ve since caused more incidents, but I try my best to not repeat the same mistakes.

New grads (and new hires generally) often have the unique opportunity to share their opinions. You’re not colored by prior experiences and biases. The things that you find odd but no one else does may actually be odd — everyone else has just gotten used to them. Keep friction logs and share papercuts. This is not just about the surfaces your team owns, but also about the various internal tools that you use on a daily basis.

However, as a new grad, there’s a mental blocker to voicing your opinion — “Am I about to say something dumb?” Thankfully, Stripe is full of kind people who are very excited to help you find your voice and are keen to hear what you have to say. They know that you’re new to the company and the industry, but that doesn’t mean your ideas will be discounted.

There are a couple techniques that you can use to start getting comfortable with sharing your voice:

As a fresh new grad, you’re still developing the instinct, taste, and knowledge to form thoughtful opinions on the fly. Even when you have a strong intuition, it’s pretty hard to convince other people that your opinion is sound without something to back it up. Bring evidence — point to some UXR, a Hubble dashboard, or a system design that supports your view. You’ll also feel a lot more confident in your opinion if you’ve done the homework. This is part of why building expertise (even if it’s narrow) is important — once you’re an expert, you will have the knowledge to cite that evidence.

It is extremely normal to vibe-check an idea with one or two people first — typically your spin-up buddy or the domain expert in that area. Even a year and a half in, I frequently DM my partners in crime before saying something more broadly. It builds confidence and filters out the occasional actually terrible idea.

You can also start small by selectively choosing the method by which you share opinions. When I started attending my org-level SHRs, I was understandably terrified of sharing an opinion. The meeting was largely full of EMs and tech leads, and I mostly just lurked, but after a much-needed push from my manager, I started leaving small messages in the meeting Slack channel. This was a lot easier than actually unmuting myself to speak up! Eventually, I gained the confidence to do that, and after months of attending, I got comfortable enough to present some of our team’s incidents — including the ones I caused :).

Careers are long, and you’re at the start! The advice above is about making early investments, but there’s more to think about as you chart a career.

There are strong compounding effects to the things you do at the start of your career. As you get comfortable at Stripe, lean into what works and push it further:

Within my first month at Stripe, my manager made me write out a career roadmap consisting of where I saw myself in five years and the concrete things I wanted to accomplish within the next year. Sure, it’s difficult to know where I’ll be in five years, but just the act of writing this down and then working backward from those long-term goals helped give me clear direction. It’s also pretty cool to see how much of what I wrote still remains true today. If five years feels too far away, try thinking just one year ahead — you may be able to come up with more concrete things you want to work towards.

The best managers (at least to me so far) feel like partners for your career. You cannot control who your manager is, but there are still things you can do to build the most meaningful and beneficial relationship with them.

Communicate a lot and often. It is easy to fall into the trap of doing great work and not telling anyone. Your manager can’t advocate for work they don’t know about. Learn how they like to communicate (Slack updates, a running 1:1 doc, weekly summaries) and keep them in the loop on both what you’re working on and how you’re feeling.

Share your goals. Hopefully your manager is already asking, but if not, tell them — and keep them updated as your goals change. The earlier they know what you want, the earlier they can steer projects and opportunities your way. This is especially relevant for perf — it shouldn’t be December and you have absolutely no clue if you’re getting put up for an uplevel.

Everyone experiences imposter syndrome, and I mean everyone. Instead of my own thoughts, here is an excerpt from a 2020 interview with @michelle (who joined Stripe as a new grad all the way back in 2013) about how you can leverage your imposter syndrome:

Some of this will be useful in your first week, and some of it will make more sense six months in. You’ll figure out what matters most for where you are and the things you specifically want to get better at.

Over time, you’ll find yourself answering questions you used to ask, making decisions you used to need help with, and taking on problems you wouldn’t have known how to start. The little area you became an expert in gets bigger, and people start coming to you for help. It’s pretty easy to miss that happening when you’re focused on everything you still don’t know.