Making better technical and architecture decisions with KIN
In the ever-evolving landscape of technology, making well-informed technical decisions is crucial to the success of a project or product. Whether you are a software developer, architect, or even a product manager, understanding how to navigate decision-making can mean the difference between success and a backlog of painful rewrites. Let’s explore some strategies and tools that can help us make better technical decisions with confidence.
Architecture North Star: The Compass for Your Decisions
One of the best starting points for any technical decision is your “Architecture North Star.” The North Star is a guiding vision that your technical infrastructure should align with. It represents your organization’s core values and goals, providing a high-level roadmap for where your technology should head.
For instance, an architecture guided by principles like “Privacy by Design” ensures that every decision considers user data security. Similarly, focusing on “Local First” architecture emphasizes working offline as a default and syncing when online. These guiding principles set a framework for everyone in the team, ensuring they have a shared understanding of the fundamental goals.
When your team encounters a difficult decision, they can revisit the North Star — those guiding principles — to determine if their approach aligns with the overarching vision. The North Star architecture effectively reduces the complexity involved in decision-making by reminding everyone of what matters most.
Technical Radars: Navigating the Landscape of Tools and Practices
While the North Star gives you a strategic vision, “Technical Radars” help you make tactical decisions about the tools, languages, and approaches that are approved, preferred, or under consideration by your organization.
Technical Radars categorize technologies into different “rings”: Adopt, Trial, Assess, and Hold. This structure helps you understand which tools are mainstream and safe choices, and which are experimental or risky. This guidance prevents teams from overreaching or adopting tools that could later become a maintenance burden. A golden stack — a consistent and uniform technology stack — is easier to maintain and reason about, ensuring that future developers will not face unexpected barriers.
Having a Technical Radar keeps the organization aligned, making it easier to see what’s supported and what’s experimental. It saves you time debating whether to adopt a specific new framework by providing a pre-assessed view of technologies that are compatible with your organization’s roadmap.
Architecture Decision Records (ADR): Documenting Important Choices
In larger projects, it’s common to find yourself faced with many potential paths forward. Architecture Decision Records (ADR) are excellent tools for capturing these choices clearly and comprehensively.
An ADR is a document that explains the context, the options considered, the pros and cons, and the reason behind a particular architectural decision. It’s a living document that helps teams understand why something was done the way it was, providing historical context for future developers.
ADRs can be shared across teams to foster collective decision-making. By making these documents accessible, organizations can learn from the experience of others. For example, an ADR might explain why your team decided on a specific database solution, laying out the trade-offs considered, and making it easier to revisit if circumstances change in the future.
Technical Decision Logs: Practical Insights on Tactical Level Decisions
Not every decision has the weight or impact of an architectural decision. Many decisions are smaller in scope but are still worth documenting. For these, “Technical Decision Logs” come into play.
Technical Decision Logs are like ADRs but cover more tactical decisions, such as choosing a specific cryptographic library for encryption or deciding how a microservice should communicate. These logs can be quick memos summarizing the choice, the rationale, and the expected impact.
The beauty of having these logs is that they give traceability to minor but important details that may need revisiting. If someone new joins the project, they can go through these technical logs and understand why certain technical routes were chosen without guessing or asking for time-consuming explanations.
Overcoming Doubts and Overthinking: Strategies for Confidence
A common challenge many technical professionals face is overcoming doubts and the tendency to overthink decisions. It is easy to get stuck in a cycle of repeatedly questioning if a particular decision is correct, especially when working on complex systems.
To overcome these challenges, it helps to rely on documented guiding principles like the North Star architecture and Technical Radars. These frameworks provide a solid foundation, allowing you to trust that your decisions are well-aligned with broader organizational goals. Journaling can also be an effective personal tool to help navigate self-doubt — recording your thoughts, assumptions, and research steps can bring clarity and reduce second-guessing.
Additionally, fostering collaboration within the team is crucial. When you engage your peers in the decision-making process, it reduces the burden of individual doubt, making the decision a collective effort rather than a personal struggle. Peer reviews, technical discussions, and group decision-making can all help mitigate over-analysis.
The Pyramid of Guidance: A Structured Approach to Decisions
In decision-making, having a clear structure or hierarchy can be extremely beneficial. You can think of this as a “pyramid of guidance” — a framework that helps you determine the sources of guidance for each decision.
At the top of the pyramid lies the Architecture North Star, which provides strategic direction. Below that are the Technical Radars, guiding the choice of tools and technologies. Further down, you have Architecture Decision Records (ADRs) and Technical Decision Logs, providing historical context and tactical details. At the base of the pyramid, you have more granular documentation, like comments in code and pull request (PR) notes, which explain the smaller, day-to-day technical choices.
This layered approach ensures that decisions are supported by multiple levels of reasoning, helping teams make more confident, consistent choices. By referring to each level of the pyramid, you ensure alignment at every stage of the decision-making process.
Time, Assumptions, and Revisiting Decisions
Technical decisions are rarely made in a static environment; they evolve with new information and changing circumstances. One important aspect of making better decisions is understanding the role of time and documenting your assumptions and unknowns.
Every decision is made based on the best information available at that time. Therefore, it is crucial to record the assumptions you had and the uncertainties you faced. If a decision later turns out to be suboptimal, it is often because new information emerged, or assumptions changed. By documenting these aspects, you can revisit and reshape decisions with a clear understanding of what has changed.
This traceability also helps create a culture of adaptability. Rather than seeing a change in direction as a failure, it becomes an informed iteration, based on newly available data. Connecting these changes to prior decision logs makes it easier to keep a coherent narrative of how your project is evolving.
The Importance of Comments in Code and PRs
Not all decisions require formal documentation, but even smaller choices can benefit from being recorded in the form of comments. Writing meaningful comments in code and in pull requests (PRs) is an effective way to document decisions that may seem minor but are crucial for future maintainability.
Good comments help explain the “why” behind code that might not be immediately understandable. They provide context for future developers, ensuring that when they encounter something that seems out of place or overly complex, they have the rationale at their fingertips. Clear comments reduce confusion and prevent unnecessary changes that could disrupt functionality.
Kin AI: Leveraging AI to Assist in Decision-Making and Journaling
The process of making and documenting technical decisions can sometimes feel daunting, especially when dealing with self-doubt or over-analysis. That’s where AI tools, like Kin, can provide significant support.
Kin AI offers features that allow you to keep journals about your decisions. Journals can be a private log where you write down your thoughts while researching, exploring, and making decisions. These journals serve as personal records of insights and assumptions you make along the way. You can record different options you considered, do a SWOT analysis, and outline your research steps. These can later be summarized or extracted as concrete records.
One of the standout features of Kin AI is its integration of “Chat and Journaling.” As you make journal entries, you can discuss them with Kin in a conversational way. Kin can help you extract key points from the journals and convert them into actionable records. Getting a summarized version of a technical journal can help you find clarity without sifting through all the raw information.
Additionally, Kin’s “Entity Extraction” feature can be immensely useful. It can extract facts from your journals and integrate them into long-term memory, providing context for future conversations. This way, when you’re discussing a similar topic later on, Kin can pull in the context from past discussions to give more informed suggestions.
AI tools like Kin are not just for software developers; they can also assist product managers, designers, and other stakeholders in making informed decisions and conducting research with more confidence and structure.
Summary
Making better technical decisions requires having the right set of tools, frameworks, and processes. From using an Architecture North Star as your overarching guide to documenting decisions via ADRs and Technical Decision Logs, and leveraging AI tools like Kin for research and reflection — each of these practices contributes to making informed and confident technical decisions. By understanding the context, documenting our reasoning, and keeping track of evolving knowledge, we set ourselves up for a decision-making process that is more effective and more resilient to future changes.