The Junior Engineer Who Taught Me About Leverage

The Junior Engineer Who Taught Me About Leverage

Three years into my role as a Staff Engineer at a fintech company, I thought I had the job figured out. I was the technical expert. The one who reviewed the hardest architectural designs. The one who debugged the gnarliest production issues at 2 AM. The one who wrote the most elegant code.

I was wrong about what mattered most.

The Surprising Observation

Maya joined our team as a junior engineer fresh out of university. Within six months, something remarkable happened: our team’s velocity doubled, our production incidents dropped by 40%, and our new hire onboarding time went from three weeks to five days.

The surprising part? Maya wasn’t shipping features. She wasn’t fixing bugs. She wasn’t even writing much production code.

What Was Actually Happening

While I was busy being the hero - parachuting into complex problems and saving the day - Maya was doing something completely different:

She was building leverage.

Here’s what she actually did:

1. She Documented Everything She Learned

Every time Maya encountered something confusing - whether it was our deployment process, our database schema decisions, or why we used a particular authentication pattern - she wrote it down. Not just for herself, but in our team wiki.

Within three months, we had comprehensive documentation that I had never bothered to write in three years. New engineers stopped asking the same questions repeatedly. They stopped making the same mistakes. They ramped up faster.

Impact: Something I could have done but dismissed as “not technical enough” work saved hundreds of hours of team time.

2. She Automated the Annoying Stuff

Maya noticed that our team spent 15 minutes every day manually running a series of database migrations in a specific order for local development. She spent half a day writing a script that did it automatically.

Then she noticed we manually updated five different configuration files before each deployment. Another script.

Then manual testing steps. Then data seeding. Then environment setup.

Each automation individually seemed trivial - the kind of thing I’d consider “not worth the time.” But collectively, they saved our 8-person team about 2 hours per week. That’s 416 hours per year. Over 10 weeks of engineering time.

The math I had missed: 4 hours of Maya’s time returned 416 hours to the team. That’s 104x leverage.

3. She Made Information Discoverable

Maya created a simple Slack bot that answered common questions:

Nothing fancy. Just a keyword matcher that linked to documentation. It took her a day to build.

Result: Our team Slack went from 50+ interruptions per day to about 15. Each interruption breaks flow state for about 23 minutes on average. Do the math: that’s saving 13+ hours of team focus time per day.

The Uncomfortable Realization

One day during our 1-on-1, Maya asked me: “Why do you always jump in to solve the hard problems yourself?”

I gave her the standard answer: “Because I’m the Staff Engineer. I have the most experience. I can solve it fastest.”

She nodded thoughtfully, then asked: “But if you solve it, only you learn. If you help someone else solve it, both of you learn. And next time, you don’t have to be involved at all.”

That question broke my mental model of what Staff Engineering meant.

What I Was Getting Wrong

I had confused being valuable with doing valuable work.

My approach:

This made me feel indispensable. It fed my ego. It matched my mental model of “senior technical leadership.”

But it also meant:

Maya’s approach:

Her impact was multiplicative. Mine was merely additive.

The Shift in Mindset

After that conversation, I changed how I evaluated my own work. I started asking different questions:

Old question: “What’s the hardest technical problem I can solve?”
New question: “What’s the highest-leverage thing I can do for the team?”

Old question: “How can I demonstrate my technical expertise?”
New question: “How can I multiply the effectiveness of everyone else?”

Old question: “What fires can I fight today?”
New question: “What systems can I build to prevent fires?”

Concrete Changes I Made

1. I Stopped Being the Hero

When a complex bug appeared in production, my instinct was to dive in immediately. Instead, I started pairing with mid-level engineers. I’d ask questions, guide them, but let them do the debugging.

The first few times, it took longer. But after a few months, those engineers could handle similar issues independently. My involvement went from 100% to 0% on a whole class of problems.

Leverage multiplier: I went from solving 1 problem to enabling others to solve all future similar problems.

2. I Invested in Infrastructure

I spent three weeks building a comprehensive local development environment that worked in one command. Previously, setting up our stack took 2-3 days of fighting Docker, dependencies, and configuration.

Three weeks felt like a long time to not ship features. But it paid back within a month, and continues paying dividends two years later.

ROI calculation: 3 weeks investment / (2.5 days saved × 40 new hires over 2 years) = 33x return on time invested.

3. I Made My Knowledge Transferable

I started running weekly “office hours” where anyone could ask questions about architecture, system design, or debugging strategies. I recorded them and put them in our knowledge base.

I created decision frameworks and templates for common technical decisions instead of making every decision myself.

I wrote “how to think about X” guides instead of just making X decisions for people.

Result: People made better decisions independently. They didn’t need me in the room.

4. I Built Tools, Not Solutions

When teams came to me with problems, I stopped giving them solutions. I started building tools that let them solve entire classes of problems.

Example: Instead of helping debug three different performance issues, I built a performance profiling dashboard that made bottlenecks obvious. The team solved those three issues plus fifteen more I didn’t even know about.

What I Learned About Staff Engineering

The job isn’t to be the best engineer on the team. The job is to make the team’s engineering better.

The job isn’t to write the most code. The job is to ensure the right code gets written.

The job isn’t to make all the decisions. The job is to create systems where good decisions happen without you.

The job isn’t to be indispensable. The job is to make yourself dispensable by making everyone else more capable.

The Irony

A year after that conversation with Maya, she was promoted to senior engineer - faster than typical. When I asked our director why, he said: “She has more impact than most of our senior engineers already.”

Meanwhile, I had to confront an uncomfortable truth: Maya understood leverage better as a junior engineer than I did after a decade in the industry.

Practical Takeaways for Staff Engineers

  1. Audit your time. Are you solving problems, or creating systems that prevent problems?

  2. Measure your impact in multipliers, not absolutes. Did you ship a feature, or did you enable 10 engineers to ship features faster?

  3. Build documentation and tooling first. The best code is the code that makes everyone else’s code better.

  4. Teach, don’t solve. Every problem you solve alone is a missed teaching opportunity.

  5. Make yourself dispensable. If the team can’t function without you, you’ve failed at building leverage.

  6. Value force multipliers over hero work. Automation, documentation, and tooling feel less impressive but have 10-100x more impact.

  7. Play the long game. Leverage compounds. Hero work doesn’t.

The Real Lesson

Maya taught me that Staff Engineering isn’t about being the smartest person in the room. It’s about making the room smarter.

It’s not about how much you can do. It’s about how much you can enable others to do.

It’s not about being irreplaceable. It’s about multiplying the capabilities of everyone around you.

The best Staff Engineers don’t make themselves heroes. They make heroes unnecessary.

../