Where Growth Gets Fuzzy: Why We Made a Rule to Lead Before You’re Ready

Over the past few years, the same conversation kept landing in my calendar. Senior engineers would pull me aside and say they wanted to scale impact as senior engineers without becoming managers. I’d hear it in performance reviews, in casual 1:1s—sometimes even after a tough production incident when things got real. Eventually, I hit a wall with the usual pep talks and hand-wavy advice. I was tired of sounding helpful while actually saying nothing. So we made it official. If you want to move up, you have to lead before you’re ‘ready.’

Here’s what it looked like to lead before you’re ready on the ground. Instead of mapping growth out on whiteboards, we paired folks who felt hesitant with hands-on responsibilities. You’re worried about working with people? Here’s an intern. Nervous about influencing product direction, own a design review. It turned vague ambition into controllable, real experiments.

But the root issue isn’t just fear. The higher you climb, the fuzzier the path gets. Titles help less and less. Once you’re senior, it’s not clear what “more” looks like. This gets tangled in the idea that there are only two roads—manager or lone technical guru. Most people freeze somewhere between, unsure what’s next.

The tension is real. Almost everyone wants to grow but dreads sacrificing hands-on work. This mix of excitement and wariness breeds inertia.

Beyond the Binary: Scale Impact as Senior Engineer by Growing Your Surface Area of Impact

If you’re wrestling with what “growth” actually means and how to grow beyond senior engineer, here’s how I see it. Stop thinking about job family switches and start thinking about how much impact you can have. You’re not boxed into either coding solo forever or chasing people-management. You can widen your reach—grow the surface area where you enable work and drive change.

Think of it like system throughput. When you’re a strong IC, your work flows directly into results. You push features, fix bugs fast, maybe mentor a bit. But once you’re senior, the lever shifts. Now it’s your job to scale engineering impact by optimizing everything around you so value moves faster and smoother. Instead of just increasing your own output, you tune the system. Code reviews improve, onboarding gets easier, decisions come quicker. The real win is that others move faster because of what you set up.

There are really three lanes you can work in to expand influence beyond coding and enable broader impact: the technical lane (making systems and architecture better), the people lane (mentoring, guiding, and connecting), and the business/context lane (making tradeoffs and strategy visible). You don’t have to pick one forever, but experimenting across them opens up new ways to lead.

So here’s the promise: we’re not going to sit in debate or rely on self-assessments. We’ll try small, low-risk experiments and see what actually clicks. You’ll move fast, learn quicker, and lower the stakes. Let’s get going.

Run the Experiment: Your 30-Day Low-Risk Leadership Sprint

Here’s your senior engineer leadership guide. Pick one experiment in each lane—technical, people, business—keep each small, and commit to running them over the next month. No prepping for months, no endless planning. Just pick, scope, and go.

Set up each experiment with a clear goal and outcome, what will change, who’s involved, and what counts as “done”? Think small—a focused design review, a shadow mentoring session, a spec improvement, a business case outline. Time-box your involvement, one or two hours max per day, so real work doesn’t get crowded out. List your stakeholders. Now carve out the recurring slots for weekly reviews—put them in the calendar and treat them as fixed. You’re minimizing risk and maximizing learnings by keeping the surface area narrow and the commitment short. This isn’t about getting everything perfect. It’s about seeing what fits.

Each week, sync up in a 1:1 with your manager or mentor. Make the agenda simple. Walk through what happened, where things got stuck, and what you want to tweak next. Don’t bury signals in dense status updates. Just name the outcomes, talk obstacles, and sketch out next steps.

Watch for signals that matter. Is your influence growing? Are things becoming less confusing? Is the risk feeling lower? Most importantly, does this type of work give you the energy to want more? If you notice you’re shaping your own role with these experiments, that’s a big sign—the proactive crafters—the ones who shape their own role through active experiments—show the highest levels of engagement and impact, across multiple measures.

Probably worth admitting here: Years ago, during a particularly rough quarter, I started taping sticky notes to my monitor just to track progress. No fancy system—just whatever was close at hand. At one point I accidentally grabbed blue notes instead of green, and that started a debate in the team about which color meant “done.” Point is, even a messy tracker works if it’s visible. Momentum isn’t about beauty, just movement.

Bite-Sized Experiments: Three Lanes, Low Risk

People lane first. If you’re worried about leading others, start on the smallest possible scale—mentor one intern for a month. Or corral a handful of folks for a weekly learning circle around a sticky topic that came up in code review. Even piloting a pair programming rotation lets you flex some influence without ever touching performance reviews. No direct reports, no HR cycle. Just simple ways to test out how it feels to help someone grow without the risk or commitment of formal management.

Technical lane next. Want to see what real ownership feels like, without getting pulled into full-time architecture? Take end-to-end responsibility for a bite-sized system—something like a small internal service or a legacy cron job that’s quietly important but rarely loved. Define clear SLOs, set up lightweight on-call rotations, pilot a mini architecture review with peers. You’ll get immediate feedback on your decisions, earn trust, and see exactly where your technical strengths land. It’s hands-on, practical, and all about scaling reliability, not just writing code.

Now for the business lane, which usually feels the most mysterious. Try this. Pick a cross-functional project—one that touches product, design, and support—and take charge of driving it from kickoff to ship. Spell out a crisp customer outcome (“Let’s reduce sign-in time by 20%”). Align the roadmap, negotiate trade-offs, and keep every stakeholder in the loop. Ship something you can measure, even if it’s small—an updated FAQ, a quicker onboarding step, a new error report. You’ll find that the rhythm of making roadmaps visible and setting clear outcomes brings the whole team onto the same page quickly, and you’ll learn what it’s actually like to balance technical needs with business impact.

Here’s where it gets interesting—sometimes the experiment itself combines multiple lanes. Facilitate a roadmap review session that clarifies technical trade-offs, updates the timeline, and pulls in feedback across teams. When it’s over, reflect: which part felt natural to you? Did you light up moderating discussions, or was speccing reliability the highlight? It’s not about nailing all three. It’s about noticing where momentum builds.

Make Your Results Count: Synthesizing, Deciding, and Taking Your Next Step

At the end of each week, sit down and actually review what happened in your experiments. What clicked, what fell flat, and—maybe most importantly—how did these activities make you feel? Don’t just tick off deliverables. Update your 1:1 agenda and bring your syntheses into the conversation. Track where you felt energy, which experiment moved the needle for your team or stakeholders, jot down any feedback you got—positive or skeptical. Sometimes the smallest tweak to your approach unblocks a lot. Noticing it is its own skill. It’s easy to skip this step when things get busy, but when you take two minutes to connect these dots, the payoff shows up in both your confidence and clarity.

Double down where you see outsized impact and the kind of energy that feels sustainable, not draining. Pick one adjacent experiment to broaden your base a bit—think of it as extending your reach, not stretching yourself thin. We’re not chasing breadth for the sake of it, just making sure your surface area grows organically, in ways you can actually maintain.

You might still wonder if you’ll lose that hands-on thrill when you step out of pure execution. I’ll be honest, that fear never fully goes away. I know it’s supposed to—plenty of books say otherwise—but somehow each new season, it sneaks back in. But here’s the upside. These experiments are intentionally small and concrete, not years-long detachments from building. Leading even one person or project will teach you more than any doc or course ever could. Try it once; you’ll see what I mean.