Technical leadership isn't about titles. It's about steering technical direction without formal authority. This skill set diverges sharply from what makes individual contributors excel. You're not managing people; you're managing outcomes through influence.
Architecture Decision Records (ADRs) offer a lightweight way to document key decisions. Each ADR captures context, options evaluated, the chosen path, and resulting trade-offs. By writing this down, you make the decision process transparent and avoid relying on fragile tribal knowledge.
I've seen ADRs work well in practice, such as when we used them to document the decision to switch from Apache Kafka to Amazon Kinesis for our data streaming needs. We evaluated options like Apache Flume and Google Cloud Pub/Sub, but chose Kinesis due to its native integration with AWS services and better support for our specific use case. This decision was documented in an ADR, which included the context, trade-offs, and rationale behind our choice.
ADR purposes are threefold. First, they create a deliberate decision-making habit. Second, they give future engineers a clear rationale for existing choices. Third, they prevent the 'path of least resistance' from becoming an unchallenged default. For instance, at one point we had to decide between using MySQL and PostgreSQL for our database needs. We created an ADR that outlined the pros and cons of each option, and ultimately chose PostgreSQL due to its better support for concurrent connections and JSON data type.
When tackling major technical changes, I've used Request for Comments (RFCs) as a structured review process. The RFC format includes a problem statement, proposed solution, alternatives considered, trade-offs, and open questions. This ensures everyone understands the scope before diving into solutions. I recall one instance where we used RFCs to propose a significant change to our API gateway, which involved migrating from NGINX to AWS API Gateway. The RFC process helped us identify potential issues and iterate on the design before implementing the change.
The RFC workflow is simple but effective. The author shares the RFC, reviewers get a week to comment, a meeting resolves unresolved issues, and the final decision is documented. This scales peer review beyond the original discussion group. In our experience, using tools like GitHub or Bitbucket to manage RFCs has been helpful, as they provide a clear audit trail and facilitate collaboration among stakeholders.
Effective technical leaders without authority share three traits. They lead by action: implementing what they advocate builds credibility. They build cross-team relationships, which extends their reach beyond their formal role. And they consistently make sound technical calls—this reputation compounds over time. I've seen this play out in our own organization, where a technical lead without formal authority was able to drive the adoption of a new testing framework simply by building a strong relationship with the development team and demonstrating the value of the framework through concrete results.
Consider the engineers who quietly shape direction in large organizations. More often than not, they're not the most senior in title. Their influence comes from execution, relationships, and a track record of good decisions—not from a management hierarchy. For example, I know of an engineer who was able to influence the technical direction of a major project by consistently delivering high-quality code and providing thoughtful feedback to their peers, even though they were not in a formal leadership role.
Strategic technical debt requires deliberate choices. Not every debt needs immediate cleanup. Some can wait until scaling, others can be ignored in stable systems. The key is recognizing which debts will hurt future capabilities and planning accordingly. We use a simple framework to prioritize technical debt, which involves categorizing debts into three buckets: critical, medium, and low priority. Critical debts are those that directly impact customer experience or revenue, medium priority debts are those that impact developer productivity, and low priority debts are those that are purely cosmetic or have minimal impact.
The framework is simple: address debt in frequently changing core systems first. Let debt in stable systems sit. For debt blocking strategic goals, allocate time to fix it. This approach balances speed with long-term health. In our case, we've found that using a tool like SonarQube to track technical debt has been helpful, as it provides a clear view of our debt landscape and allows us to prioritize debts based on their severity and impact.