Senior engineers amplify through team success, not individual output. The leverage formula applies directly to career development: the highest-return activities multiply team effectiveness, they don’t just add to your own.
The key insight: the most visible, most impactful technical contributions at a company level are almost never feature work. They’re the infrastructure improvements that make feature work easier, safer, or faster for everyone else.
Finding the opportunity
Diagnose before you propose. Ask:
- Where do incidents keep originating from? (Reliability gap)
- What causes the most friction in code review? (Convention or tooling gap)
- What knowledge would cause real disruption if it disappeared? (Bus factor)
- Where do engineers slow down the most? (DX or feedback loop gap)
- What keeps going wrong despite being “fixed”? (A structural problem wearing a patch)
- What can’t the team currently see? (Observability gap)
- What takes longest in the deploy pipeline? (CI/CD bottleneck)
These questions surface the problem. The proposal is the solution, with an explicit leverage calculation attached: what’s the before/after impact on team velocity, incident rate, or developer time?
Architecture
High-leverage architecture proposals find the seam where the system is painful to change, then propose a migration path that improves things incrementally.
Look for: where multiple teams keep stepping on each other (a missing boundary), where a change in one area routinely breaks another (excessive coupling), where adding a feature means touching ten files (the wrong abstraction layer), where the monolith is making new work harder than it should be (a migration target).
What makes a proposal land: a concrete before/after (“this reduces the files touched for X-type features from 8 to 2”), an incremental path (“here’s the strangler fig migration starting with this seam,” not “let’s rewrite”), a measurable definition of done.
What kills a proposal: “future-proofing” as the rationale, a big-bang rewrite with no incremental fallback, architecture proposed to solve what’s actually a people problem.
Testing infrastructure
Testing proposals carry high leverage because they multiply every engineer’s confidence and cut the cost of every future change.
The highest-return improvements: eliminating flaky tests (a flaky test is worse than no test, it trains people to ignore failures, and the decay stays invisible until it’s severe), cutting test suite time (three minutes down to thirty seconds is a permanent productivity gain for every engineer on every PR), covering the critical paths that show up most often in incidents, and better tooling (httptest-based fakes for downstream services, shared fixtures, factory builders) that makes writing a good test the easy default.
CI/CD
CI/CD improvements are force multipliers. A pipeline that runs in eight minutes instead of twenty helps every engineer on every PR, indefinitely.
Look for: what’s the p50/p99 pipeline time, and where does it go? How often do engineers push and find a CI failure they could’ve caught locally? Where does a deploy need manual steps or coordination? How long does a rollback actually take?
High-leverage moves: parallelize the pipeline (most run steps sequentially that could run side by side), surface the most common failure first (if go vet or lint failures dominate CI, run that check first), invest in deployment safety (feature flags, canary deploys, automated rollback, all of which lower the perceived risk of shipping and raise how often people actually ship), and preview environments (an automatically deployed test environment per PR changes review, QA, and product feedback all at once).
Observability
You can only manage what you can see. Observability gaps let incidents go undetected and slow down diagnosis once they’re found.
High-leverage moves: alert on symptoms (user-facing error rate, p99 latency) rather than causes (CPU, memory), add distributed tracing so a request can be followed across service boundaries, make logs structured and queryable instead of just greppable, and internalize the normal range for critical metrics so an anomaly is recognizable on sight.
Developer experience
DX improvements scale with team size: a one-hour improvement to the dev setup pays back at team size times frequency of use.
Look for: how long does a new engineer take to reach a running local environment? What “why isn’t this working” questions repeat in team channels? What tribal knowledge is required that’s never been written down?
High-leverage moves: cut day-one-to-first-commit time, fix flaky local environments (a tax every engineer pays every day), and write error messages that say “you need to set X because Y,” which is worth hours of collective debugging saved.
Knowledge distribution
Knowledge concentrated in individuals is fragile. Distributed knowledge compounds.
High-leverage moves: an architecture documentation sprint (a week of diagrams and ADRs for the parts of the system that have neither, paying back for months in reduced onboarding friction), a runbook library (documented response procedures for every known failure mode, especially valuable for on-call), internal tech talks on non-obvious system behavior or lessons from incidents, and a real postmortem culture that produces written artifacts and becomes the team’s institutional memory over time.
How to pitch it
A proposal that lands has four parts:
- The current cost, quantified. Time, incident rate, error rate, engineer-hours. Not “it’s painful,” but “it costs approximately X per week.”
- The proposed change, specific and incremental. Not “improve the testing story,” but “eliminate the twelve known flaky tests in the transfer flow by switching to
httptest-based fakes for the card-network calls.” - The expected improvement, measurable. “Reduces CI failure noise by roughly 30% based on current failure rates.”
- The scope, bounded. A proposal that fits in one or two sprints gets approved and finished more often than one that needs a quarter. Start small, prove the value, expand from there.
The highest-leverage career move is finding problems invisible to everyone else, because you did the diagnosing, proposing a solution that benefits the whole team, and delivering it incrementally enough that the value shows up before the full cost does.
That’s the series. Six principles, a set of named patterns, and the practices that sit around them: how to learn a codebase, review a PR, and pitch the work that actually moves a team forward. None of it is complicated. Most of it just takes longer to internalize than it does to read.