Decision Model
How do you make Technology Decisions in your organization? In this post, I dive into how an organization can improve its technology decision-making process.
How do you make Technology Decisions in your Organization? If you are an Architect, Tech Lead, Staff Engineer who has to make technology decisions - it is essential to apply some metacognition about decisions.
Following are the typical patterns.
Decisions by Default
Happenstance. Allows accidents to turn in decisions; the first google search becomes the product of your choice. That new fancy JavaScript framework that appeared in Hackernews is your application framework.
Sometimes, teams are not even aware they are making decisions that significantly influence the Team's future.
Top Down
All the decisions roll up to a single person, and this could be a Team lead or an Architect, or Director of Engineering - This is often a sign of a weak team and poor leadership. The decision quality suffers depending on the decision - Decisions that require broader context are less impacted, however, decisions that need deep technical knowledge or intimate knowledge of the Team might suffer.
Decision Model
Using Decision Models is my favorite approach; Everyone in the Organization clearly understands how technical decisions are made and plays a role. The Team considers decisions as a product and performs peer reviews of decision documents, and solicits critical feedback to improve decision quality.
Decision models also provide a framework to engage other stakeholders - The business or Product teams that otherwise might have missed. As it often happens, product teams might have unique insights that can invalidate or strengthen your assumptions.
A decision model tells everyone
- Who can make what decision
- How to make a decision
An example of "Who can make what decision?" : You need the Engineering VP or Director level approval to add a new programming language to the stack but only need your team consensus to add a new backend library. "Who" could be multiple individuals from different teams, for example, head of engineering and VP of product.
An example of How: The "How" part outlines what homework is required to decide. For example, Adding a library only needs a quick conversation with your Team and comments on your commit notes; adding a programming language warrants a decision document that outlines the motivation for the decision, pro/con, the total cost of ownership, impact on the Team.
One might think that a decision model is bureaucratic; however, it does the opposite; it tells the Team what is required to make a new decision. It avoids guesswork and provides a clear path for engineers to suggest new ideas. The decision model also acts as a threshold for the Team to push only for a decision they are willing to put effort into.
What decision model is not: It is not the decision by committee; even though it engages multiple stakeholders to collect information is not the same as the decision by committee. Individuals own the decisions, and they are responsible for making sure that they are producing high-quality choices.
Organizations that understand the leverage of high-quality decisions consider technical decisions as deliverables. They maintain good Decision models, templates, or examples for the Team to write the decision documents.
Summary
If you lead an Architecture or Engineering organization, you might want to consider building a decision model to organize and catalog your technology decision-making process to improve your overall technology strategy.