DoorDash Reflections

Three years ago in 2022 I joined DoorDash as an engineer. The time has taught me things school, blogs, and onboarding never did.

Engineering isn’t just building things. It’s knowing what matters.

Here are 9 engineering moves that 10x your impact:

Outcome Mindset

📈 1. Code is Cheap. Business Impact is Not. Why measurable outcomes trump elegant code

I got into programming through math-heavy problem-solving platforms like Project Euler, Codeforces, and Hackerrank.

I loved the purity of it: tight loops, optimized runtimes, the elegance of correctness.

It trained me to chase optimality.

But once I started working full-time on real software teams, I ran into a different truth:

You can write the cleanest, most efficient code in the world and it might get deleted next quarter. Look how they massacred my boy.

Entire systems are rewritten.

Roadmaps shift overnight.

Features die if the numbers don’t move.

I’ve seen beautifully engineered tools get sunsetted, while a duct-taped MVP built during a hackathon drove a double-digit lift and got company-wide visibility.

That’s when it clicked:

Your job isn’t to write elegant code.

It’s to drive outcomes that matter.

If something doesn’t make business sense, it will be killed.

If something shows potential, it will get resources.

That’s the game.

So zoom out.

Understand the “why” behind your work.

Know what your team and your company actually care about.

It’s not your design pattern.

It’s the impact.

This doesn’t mean writing bad code.

It means writing appropriate code for the business context.

Align with the strategy. Build what moves the needle.

And let go of perfectionism when it’s not serving the mission.

🎯 2. Design for Learning, Not Just Launch. A/B tests reduce risk, resolve ambiguity, and help you grow

At DoorDash, experimentation wasn’t optional; it was how we operated.

At any given time, we had so many tests running across pricing, logistics, UI flows, you wouldn't even believe it.

Sometimes, a single feature sat inside multiple overlapping experiments.

Managing that level of complexity wasn’t trivial.

It required tight coordination across product, analytics, and engineering to avoid conflicts and extract clean signals.

But here’s the deeper lesson:

Experimentation shines when there’s no clear answer.

When tradeoffs are murky.

When teams disagree.

When intuition runs out of road.

A good experiment unblocks the team. It resolves ambiguity.

It replaces opinion with evidence.

That’s what senior engineers do:

Not just ship code, but design systems that learn.

It’s not about running more tests.

It’s about running smarter ones.

Define the metric before you build.

Know what success looks like and what you'll do with the result.

Partner with analytics early.

Anyone can A/B test.

But if you want to operate at the Staff level and beyond, build the kind of feedback loops that make your team smarter every sprint.

Evidence beats ego.

Every time.

TODO: A/B test heading and subheading

🚀 3. Growth Is a Game of Inches. How compound gains fuel growth

Big wins are rare. Real growth comes from a thousand small ones.

You don’t need 10x ideas.

You need 1.01x improvements—over and over again, consistently.

At DoorDash, we made the smallest changes imaginable:

• Tweaked button copy
• Tuned retry logic
• Cleaned up logging
• Reordered onboarding screens

Each change added a tenth of a percent.
Together, they compounded into real business impact.

That’s the game: test, ship, measure, repeat.
It’s not sexy, but it scales.

Success isn’t a hero refactor or a big-bang redesign.

It’s operational discipline.

It’s knowing your input metrics, aligning the team to stretch-but-realistic goals, and holding the line every sprint.

You don’t build a rocket.

You build a ramp. To outer space.

So commit to the discipline.

Test. Ship. Measure. Iterate.

If you can improve by just 1% every sprint, that’s all you need.

“I'd rather die chasing excellence than live being mediocre.” ― Tony Xu, CEO of DoorDash

Adaptive Practice

📚 4. Optimize for Learning Throughput. Throughput isn’t just for systems

Early in my career, I used to chase mastery: reading all the docs, bookmarking every edge case, trying to "know everything" before shipping anything.

But the truth is:

Real-world engineering doesn’t reward static knowledge.

It rewards speed of adaptation. Speed of insight. Speed of clarity. Not just for yourself, but for your team.

The best engineers treat learning like a throughput problem:

• How fast can I go from question → experiment → insight → outcome?
• How quickly can I reduce time-to-impact in a new domain?
• Can I leave behind a system others can ramp on twice as fast?

When I joined new teams, I started optimizing for that loop:

• Pair with the domain expert instead of getting lost in outdated docs
• Write one clean diagram instead of explaining the system ten times
• Turn Slack threads into a self-serve FAQ that saves everyone hours

I stopped trying to be the smartest person in the room.

Instead, I focused on reducing “time-to-understanding” for everyone.

Because hoarding knowledge to seem irreplaceable isn’t senior. It’s insecure.

It creates bottlenecks, breeds mistrust, and slows the team down.

The people who operate at a Staff or Principal level?

They make everything around them easier to understand.

They leave trails.

They lift others up.

Read less. Build more. Reflect often. Leave behind clarity.

That’s how you compound learning into leverage.

🧘‍♂️ 5. Don’t Fight Stupid. If you gaze long into an abyss, the abyss also gazes into you

Early in his career, Bob jumped into every debate.

Tried to fix every broken process. Argued every stupid. ¯\(ツ)/¯

It didn’t work.

It drained energy, created tension, and didn’t change outcomes.

Eventually, Bob learned:

You don’t fix dysfunction by fighting its outputs.

You observe.

You trace the pattern.

You wait for the right moment

Then intervene at the root.

Sometimes that means letting the wrong decision play out until its flaws become undeniable.

Sometimes it means having a quiet 1:1 instead of a public teardown.

Sometimes it means realizing the “bad” idea actually made sense under constraints you hadn’t seen yet.

Being right is easy.

Driving impact is harder.

When something seems off, pause. Listen.

Ask: What’s the system that allowed this?

Don’t fight stupid.

Observe and address root causes instead.

🔍 6. Read the Plain Code. In an AI-assisted world, understanding existing systems is your edge

Docs drift. Specs lie. Diagrams are often outdated.

Prod code is the only receipt reality signs.

Before you refactor it, replace it, or build something “better,” stop and study it.

Not just what it does

But why it exists that way.

What tradeoffs shaped it.

What breaks if you’re wrong.

This used to be common sense. But with AI tools writing more and more code, it's never been easier to skip the thinking part.

You can generate a new implementation before you even understand what the old one solved.

That’s dangerous.

As abstraction increases, so does the risk of:

• Silent logic bugs
• Broken contracts
• Invalid assumptions
• Unintended regressions that only appear in production edge cases

Senior engineers don’t just write code.

They trace decisions back to their origin.

They read before they write.

AI can help you move faster. But it also raises the cost of skipping understanding.

So slow down.

Read the code.

Trace the flow.

Hit the edge cases.

Pass the tests.

Only then build.

The faster the world moves, the more important it is to understand what’s already true.

👉 If any of these 9 principles resonate, share with the engineer you were 2 years ago.

Leadership Levers

🤝 7. Recruiting and Team-Building is Your Highest Leverage Activity. Great engineers write code. Great leaders shape who’s in the room

Early on, I thought engineering impact meant writing great code.

Later, I learned: your biggest impact might be who you bring in to write it with you.

The systems, culture, and velocity of a team are downstream of the people in the room.

Every new hire shifts the surface area of what the team can build and how well it can build it.

I’ve seen what happens when you get it right:

When a hire clicks fast, contributes clearly, and raises the bar across the board

Code quality improves.

Reviews get sharper.

Ownership becomes obvious.

You don’t just gain velocity

You gain lift.

I’ve also seen what happens when a hire creates friction.

Even subtle misalignments can slow decision-making, drain trust, and quietly shift culture in the wrong direction.

So now I treat recruiting as part of the system.That means staying involved in:

• Sourcing
• Calibration
• Loop design
• Onboarding
• Even how knowledge compounds once someone joins

ROI ≥ e^(team_quality * time)

People compound faster than processes.

Hire accordingly.

Invest accordingly.

⚖️ 8. Hold Opposing Values Simultaneously. Move fast AND don’t break prod

Most things in engineering aren’t black or white.

They’re grey, shifting, and tangled in tradeoffs.

Move fast or don’t break things?

Ship now or build it right?

Optimize for product or infra?

False dichotomies like these show up all the time.

Juniors always want to pick the “right” answer.

But a Senior knows not to pick sides—they hold tension instead.

They understand both arguments.

They ask, “What’s true here?” and “What’s true there?”

They sit in the ambiguity long enough to make better decisions without rushing to false clarity.

This isn’t a soft skill.

It’s a technical strength.

It takes cognitive flexibility to hold speed and stability,

to fight for quality and pragmatism,

to make tradeoffs with full awareness of what you’re giving up.

🛡️ 9. 100% Ownership is Non-Negotiable. Real owners don’t wait to be asked

Every manager I've ever had praised me for my extreme ownership mentality.

It wasn't hard. I simply cared more than they did.

At times I’ve cared too much.

Ownership isn’t about doing your part.

It’s about closing the loop completely.

That means:

• Fixing the bug
• Then fixing the system that let the bug through
• Writing the doc
• Updating the runbook
• And making sure it never happens again

Once, I got paged for an outage in a service I didn’t even own.

But users were affected and our team was adjacent.

So I picked it up, traced it, patched it, and wrote the post mortem RCA.

Because the impact was real.

That’s the bar.

Ownership isn’t a behavior.

It’s an identity.

You don’t act like an owner when it’s convenient.

You operate that way by default. Consistently.

Especially when it’s hard, ambiguous, or outside your lines.

If the system’s broken and you saw it… you own it now.

I burned a lot of nights before these 9 plays stopped being theory and started living in my muscle memory. If they help you skip even one head-on collision with reality, mission accomplished.

👇 Got an off-menu engineering lesson of your own? Drop it in the comments

Want more systems-level tactics at the crossroads of engineering, AI, and growth? Subscribe

— Brian