Introduction
One of the reasons that a wrong technical decision comes back to bite us is not so much because the decision was actually wrong. It is often because that decision was either made without the decision makers understanding its full implications or, even more frequently, because the decision makers were not aware that they were actually making a decision to begin with. It was an unconscious decision. In other words, it is the lack of awareness or lack of decision mindfulness that is the core of the problem. We'll come back to that in a bit.
Before we continue, let's clarify what we mean by "Technical Decisions". These are the decisions that have to do with coding/implementation, software design, architecture, choices of vendors and integration with third parties. Needless to say, there are also non-technical - ie product and business decisions that are equally important. This article (and overall Architectural Tradeoffs series) focuses on the technical side of things and on the intersection of tech and business.
Also, let's level set on some terminology:
MVP | Minimum Viable Product |
POC | Proof of Concept |
Monolith | Stand-alone application that performs all or most of the functionality. |
Serverless | Paradigm where application runtimes and deployment are managed largely by the cloud. |
Microservices | Fine grained, decoupled, separately deployed applications where each application takes care of a specific piece of functionality. |
Also, although I am referring to startups in this article, most, if not all of what is being discussed applies to any kind of a tech team/organization.
What is This All About?
How to increase confidence in our technical decisions is a topic that, for some reason, I have rarely seen discussed and yet it is absolutely key in establishing a healthy technical and architectural strategy that can serve the organization as it scales and grows.
Let's have a look at the life cycle of a typical startup that withstood the challenges of the market and has put itself on the path of growth. There are many popular models out there that describe this lifecycle in any number of stages and are all compatible since each of them takes a slightly different perspective.
Below is just a mental model that I've put together over the years to help me visualize that kind of a lifecycle with an emphasis of where decisions are typically being made.
What the above mental model shows is that we start making most of the long lasting technical decisions at the MVP phase.
Note that this is where we begin making these types of decisions. The decision making process never stops. The difference between decisions being made at the MVP phase (and onward) and decisions made during the POC phase (and prior) is that POC-stage decisions are typically temporary. They are made just to get some resemblance of a product out of the door as fast as possible. Often, these are not even fully functional products but more of visual representations to demonstrate the end result.
MVP-phase technical decisions are where we have to start paying attention. This is where Technical Decision Mindfulness comes into play. In other words, technical decisions made at this point will typically have long lasting ramifications as these decisions will be built upon. They will influence other decisions later on and will steer the course of the organization (at least as far as technology goes).
Are Wrong Decisions Always the Actual Problem?
Here's something to keep in mind. Remember, how at the beginning of this, we said that it isn't necessarily the actual decision that is the problem but instead, it is the lack of awareness in how that decision is made? The reason for that, although may seem counterintuitive, is that a wrong decision can oftentimes be addressed with minimal impact to the business. If it is identified and addressed in a timely, streamlined manner and if there is a clear process to pivot that decision, it will not have as dramatic of an effect as it could have otherwise.
This can only happen if the decision was made in a mindful manner where there was awareness and structure of the fact that a decision is being made and how it was made.
Example
Now, that was a lot of abstract talking. Let's dive into a concrete example. Let's imagine a startup at an early MVP stage. The team is working on a SaaS product that aggregates some kind of data and exposes it to the outside world.
As such, the team has to decide how exactly it would deploy their SaaS offering. What would the infrastructure look like? How would the application be structured? There are any number of ways to structure the application and deploy the product. Options abound.
Some options* that the team is facing are (assume we are leveraging AWS as the cloud provider):
Monolith
Structure the service as a monolith application. Plop all the functionality in there. Deploy in a managed container orchestration service. One DB. One application.
Microservices
Design your service such that it is composed of microservices from the very beginning. There are multiple services with multiple databases. Everything is deployed in a container orchestration service.
Serverless/Functions as a Service
It's all the rage nowadays. We can make use of AWS Lambda for running the application and DynamoDB as the database. AWS does the heavy lifting as far as running it all.
* The architectural diagrams above are missing a lot of detail. They are there just to convey a rough visual representation.
Guidelines
So which one should the team choose? What are the implications? How far reaching are these? How much effort should go into analyzing each of the options? These are some of the questions that are hiding between the lines. It doesn't help that there are also combinations of the above choices and within each of these choices there are…more choices!
Now, this is that crucial moment in time where the team needs to make a conscious and justified choice. Notice that it does not necessarily have to be the right choice, because there can be more than one and because what is "right" may change depending on more context in the future.
What often happens is that the team will make the decision implicitly, unconsciously, or with no or limited understanding of the implications.
So what should the team do? How would they ensure that they are making their choice in such a way that it serves the organization in the best way possible? By being aware of and following these guidelines:
Keeping Records
If there was one thing that you took from this article, it would be this. It seems like it should be the easiest thing to do and yet I have seen very few teams who diligently document their technical decisions.
I get it. Documentation is not the most fun thing to do - especially when you are consumed by building the next big thing. Yet, it takes only a fraction of time and the far reaching benefits of clearly documenting your technical decisions is immense and will keep paying for itself ten/hundred/thousand-fold in perpetuity.
Whenever faced with a technical decision and making a choice of any significance, document when and why that choice was made. It doesn't have to be a huge document or anything complex. The following would suffice:
✅ When we made the decision
✅ What were the options
✅ What were the pros and cons of each option
✅ Why we went with a particular option
✅ Potential concerns
In an established team/organization, you may want to use something more official such as an ADR (Architectural Decision Record). However, for an MVP level venture - the above will suffice.
Such records will allow you to go back and understand why decisions were made as such and will do much in preventing confusion later down the road. It will also help you uncover any pitfalls with these decisions early on. This brings us to the next point:
Revisit Your Decisions Regularly
Remember how earlier we said that making the "right" choice is often not as important as making a "conscious" choice? That's because the "right" choice today may be the "wrong" choice a year from now. By revisiting your technical decisions, reevaluating them, brainstorming them with the team, you will always have a hand on the pulse of the technical state of the organization.
Have these as a regular cadence. Have a session or two per month. Or a session once every two months. Or a whole day every quarter. It doesn't matter. The important thing is that you are having these sessions continuously and are committed to using them as a regular pulse check to identify which technical solutions still work and which do not.
There is more though.
Always Ask Questions (Especially When There are Problems)
Question your technology choices. Project into the future based on company goals and how these align with the current technical state of things. Can things be made better? How?
The thing that will help you most here is being keenly aware of the technical issues being encountered by your product. Is there a scalability problem? High error rate in production?
Users waiting 20 seconds for the site to load? Infrastructure giving out every Monday and Thursday?
These issues are the best indicator that something needs to change and that some technical decisions need to be revisited and/or made.
Keeping tabs on these problems, documenting them, and asking how they can be solved (and hopefully documenting your findings too) is a good way to start that process.
Conclusion
At the end of the day, you can't guarantee that a decision or technology choice that was made today, will serve the organization well forever. With the ever-changing landscape of technology and business needs, organizational pivots, market trends, and other forces, it is challenging to predict with any degree of accuracy how all of these choices shape the future of the organization's technical state.
However, there is much that can be done in terms of laying out a clear, intuitive, and streamlined decision making process that optimizes these decisions and provides ways of pivoting and changing them as circumstances change.
This is the process that will ensure that the architectural tradeoffs we make are the right ones for the time and conditions we are operating in.
If your team needs help in establishing processes that optimize technical decisions or with deciding between concrete architectural or technical options, you can always engage us at CloudWay Digital.
Comments