Staff+ Engineering Influence & Communication

A document proposing a technical decision or change for review and feedback before implementation. Describes the problem, proposed solution, alternatives considered, and trade-offs. The goal is to achieve alignment and surface concerns before committing to a direction.

"Before starting the database migration, I wrote an RFC: problem statement (the current schema doesn't support multi-tenancy), proposed solution (tenant_id column strategy), two alternatives (separate schemas, separate databases), trade-offs table. After two weeks of async review with 12 engineers, the RFC was approved with one modification: switching tenants gets a separate RFC. We avoided three months of wrong-direction work."

A short document capturing an architectural decision: context (why the decision was needed), decision (what was chosen), consequences (what this means going forward). Stored in the repo as a living record. Future engineers can understand why things are the way they are.

"We have 47 ADRs in /docs/adr/. ADR-0023 records why we chose PostgreSQL over MongoDB in 2021 (strong consistency needed for financial transactions, team familiarity, existing pg expertise). When a new engineer asks 'why aren't we using MongoDB?' the ADR has the answer — and the constraints that led to it, so they can judge if it still applies."

Achieving organisational change and technical decisions through persuasion, demonstrated expertise, building relationships, and framing arguments — rather than through formal management authority. A core Staff+ engineer competency.

"I had no authority over the platform team, but I needed them to prioritise the observability initiative. My approach: documented the incident cost of poor observability ($2M in two incidents), built a prototype showing what better tooling looked like, found three other engineering leads who shared the pain, and presented the combined case to the platform team's director. The initiative was funded. Influence without authority."

A long-term picture of the desired technical state of the system, used to align decisions and trade-offs across teams. A north star helps teams evaluate current decisions: 'does this move us toward or away from the north star?' Not a roadmap — a direction.

"I wrote the platform north star document: 'By 2026, any engineer can deploy a production-ready service in one day, with observability, scaling, and security built in by default.' Every platform decision is now evaluated against it. A request to add a new manual onboarding step fails the north star test immediately. It's become a shared reference for prioritisation debates."

Structuring a technical communication so the audience immediately understands the business impact, not just the technical details. Answer 'so what?' before the audience asks: translate technical findings into consequences for the business.

"Bad framing: 'P99 API latency increased from 120ms to 340ms.' Better framing (so what?): 'API latency tripled, which our A/B tests show reduces checkout conversions by 3.2%. At current traffic, that's $400K/month in lost revenue. I recommend rolling back the caching change this week and investigating the root cause.' The second version gets executive attention and a decision."

Formalising an informal practice that has already emerged organically because it works well — instead of imposing a new standard from the top down. When engineers keep solving a problem the same way independently, make it the official way.

"Twelve teams had independently built similar feature flag integrations. Instead of mandating a new platform-team solution, I surveyed all 12, found the most common patterns, and 'paved the cowpath': wrote the official documentation based on what was already working, extracted the shared code into a library, and deprecated the variants. Adoption was immediate because it was already how teams worked."

Decision-making frameworks that clarify roles. DACI: Driver (facilitates the decision), Approver (makes the final call), Contributor (provides input), Informed (kept in the loop). RACI: Responsible (does the work), Accountable (owns the outcome), Consulted (provides expertise), Informed.

"Before the platform migration planning started, we filled out a DACI: Driver — principal engineer (me), Approver — VP Engineering, Contributors — tech leads from 5 teams + security, Informed — all engineering managers. This prevented the common failure mode where everyone thinks they have veto power and the decision stalls. Three weeks later, we had a decision."