Making Sound Technical Decisions

Making sound technical decisions as a software engineer can be quite difficult and as you progress in your career you will be responsible for making decisions on your teams ways of working as well as how to design and architect software solutions that have a positive impact on your companies bottom line.

In this blog post we discuss 4 fundamental steps you can take to be more successful when starting new technical projects as well as make sound technical arguments to better sell your ideas.

Identify facts

The first thing that you want to do is identity facts, facts are pieces of information about a topic of discussion that can be verified. Facts are not up to debate. For those of you with knowledge of discrete mathematics, this would formally be called propositions. It’s a declarative sentence with a definite truth value. Propositions are the building blocks of logical reasoning and are used in areas like set theory, logic, and proofs.

Here are two examples:

• CI pipelines for our backend end projects are taking on average 45 minutes to run.
• The latest version of Scala supports incremental execution.

It’s also important to differentiate between facts, opinions and feelings and build your technical decisions on solid reasoning. Doing so, you are more likely (although not guaranteed to) to create a more convincing argument for your technical decision.

Identify priorities

The second step involves identifying the priorities of everyone involved, including yourself. Doing this could mean looking at a given situation from the perspective of the most important stakeholders and identifying facts that might matter to them and using these facts to bolster your argument so it can be more persuasive.

Draw Conclusions

Once you’ve got the facts and figured out what everyone’s priorities are, you should be able to draw some conclusions.

Let’s look at an example, suppose you are the new team lead in an existing project that is facing challenges, a digital-first, cloud-native home loan origination system.

After taking the time to talk to existing team members about the challenges the project was facing, you identify important facts:

As part of this project, your company needs to let customers refinance home loans entirely in the app. However, from an architectural and engineering perspective, this initiative was challenging because this involves

• Over 440 possible steps due to the unique requirements of each borrower
• Complex compensations and state management
• A combination of human-in-the loop and automated tasks
• An inherited workflow engine that slowed down innovation

So after understanding these facts and identifying the companies priorities you conclude that your team needs to modify the existing system to streamline complicated workflows and reduce manual overhead. During your research you also identify how a project called temporal can dramatically improve efficiency and simplify the overall system.

Your team builds a PoC and you present it to the broader engineering team. Everyone is convinced that this is a great solution and you get buy in from the VP of engineering, the CTO and other technical leaders.

Such a happy ending can only be possible if you identify facts, priorities and use this information to build sound arguments and use them to draw conclusions

but it doesn’t end there…

Document the Technical Decision

You also need to document the decision making process in an architectural decision record or some other document type. An architectural decision record is a document that captures an important architecture decision made along with its context and consequences.

Making technical decisions can be challenging but by identifying facts, identifying priorities of the most important stakeholders and using this information to draw conclusions will help you make sound technical decisions that earn the respect of other engineers and have a positive impact on the companies bottom line.

For updates about the blog and software development tips, follow me on X @0xFFA4.