Leading technical strategy without formal authority is the reality most senior engineers face, and Henry Wilson's account of the BBC Sounds re-architecture makes one thing clear: software architecture is a social discipline, not a technical one. We agree wholeheartedly. Wilson's tools, RFCs, ADRs, and deliberate relationship-building, are not new, but his framing of them as weapons against organizational inertia is refreshingly direct. The hardest part of architecture isn't choosing a database; it's convincing a room of skeptical peers that your tradeoffs are worth their trust.
For anyone who has watched a promising technical direction stall because a single senior voice refused to budge, Wilson's discussion of "active resistors" will feel personal. He doesn't suggest overpowering them. Instead, he advocates for understanding their constraints and building buy-in through transparent documentation and incremental wins. This approach mirrors a challenge we see in other fields. Consider the frustration voiced in When Presenters Can’t Answer Questions, AI Papers Fail the Test. There, the failure is also one of communication, papers that cannot withstand scrutiny because their authors cannot explain their own work. In both cases, authority is earned through clarity and openness, not granted by title. Wilson's lesson is that a well-written RFC can do more for your strategy than any org chart.
The practical takeaway here is blunt: stop treating technical strategy as a document you write alone. Wilson's success came from making architecture a conversation, not a decree. That means writing RFCs that invite dissent early, using ADRs to capture why decisions were made (not just what was decided), and spending as much time in one-on-ones as in code reviews. If you are a senior engineer frustrated that your vision isn't moving forward, ask yourself whether you have built the social scaffolding to support it. The BBC Sounds team didn't need a re-architecture because the old system was broken; they needed one because the organization had outgrown its ability to align around technical choices. Sound familiar? It should. Many UX professionals inside large organizations face the same structural friction, as Explore a new community built for UX professionals inside organizations highlights. The common thread is that influence without authority requires a playbook, and Wilson has given us one.
One specific detail from Wilson's approach is worth watching closely: his emphasis on "balancing tradeoffs" as an explicit, documented step. Most engineering leaders talk about tradeoffs but rarely write them down in a way that survives a single meeting. If you adopt nothing else, adopt the habit of recording why you chose one path over another, including the costs. That record becomes your strongest tool when the resistor comes back six months later asking why you didn't pick their preferred solution. The answer isn't "because I said so"; it's "because we agreed on these tradeoffs, and here is the document that proves it." Authority, in the end, is just the memory of good decisions that were made transparently.