Technical leadership is about influencing direction without formal authority, and that's a different skill set entirely. The skills that make technical leaders effective are different from the skills that make individual contributors effective.
The architecture decision record
ADRs (Architecture Decision Records) provide a lightweight format for documenting significant technical decisions: the context, the options considered, the decision made, and the consequences. ADRs serve multiple purposes: they make decision-making explicit and reasoned, they provide context for future engineers who inherit the decision, and they create a practice of deliberate decision-making rather than implicit path-of-least-resistance choices.
RFC culture for significant changes
An RFC (Request for Comments) process for significant technical changes creates structured peer review. The RFC format: problem statement, proposed solution, alternatives considered, trade-offs, and open questions. The process: author circulates the RFC, reviewers have a week to comment, a decision meeting resolves open questions, and the outcome is documented. The RFC process scales the review of significant decisions beyond the small group who were in the original discussion.
Earning influence without authority
Technical leaders who are effective without formal authority share traits: they do the hard work first (implement the thing they recommend, so the recommendation comes with proof), they build relationships across team boundaries (their influence extends to teams they do not manage), and they are consistently right about technical trade-offs over time (credibility compounds). The engineers who are most influential in large organisations are rarely the most senior in title.
The art of strategic technical debt
Not all technical debt should be paid immediately. Technical leaders make explicit decisions about when to accept debt (speed to market), when to reduce it (before scaling), and when to ignore it (mature stable systems that are not changing). The framework: debt in a core system that changes frequently should be addressed before it compounds; debt in a stable system that rarely changes can be tolerated; debt that blocks the next year's strategic capability needs a funded reduction plan.