DEV Community

Yugo Sakamoto
Yugo Sakamoto

Posted on • Updated on


4 actions to help you make good technical decisions

At some point in our development career, we collect enough experience and start leading technical decisions for our teams.

Some of them can be exciting, but others very challenging if you don’t do the right trade-offs.

There are many approaches and plenty of content on the web. Here are my 4 essential actions to help you make good technical decisions:

Understand the real problem

The real problem is the root of every technical decision you do.

Rather than implement a Microservice or Monolithic architecture, use React or Angular, you can only make good choices when you understand the real problem and put it in the center of your trade-offs.

No matter how great you craft something if no one needs it, right?

Make sure to have a clear and well-defined problem. Be present in business discussions. Connect every decision you make with the business problem it solves.

Once I thought since I’m a tech guy, I can focus exclusively on technologies and architectures, and let the business decisions to the business guys.
In the end, I see myself wasting time concerned with things with no real value and trying to fix issues no one cares about.

Evaluate your team skills

Teams are very unique. Each member has its own background and skills at different levels.

Evaluating your team skills is important to get the right tools and frameworks that enhance team productivity as a whole. Since software development is a group task, rely on a highly effective team is better and safer than on a single highly effective developer.

Involve the team members to figure out the best decisions for the whole team’s productivity. Make the entire process transparent for everyone to collect honest feedback.

Once I was responsible to decide the technology stack for a new project. I’ve made a lot of research and comparisons between the best options available at that time all by myself. When I finally came up with my “best stack”, it might have worked to build the solution, but isn’t the right one for the team very late.

Experience the end-users routine

Experiencing the end-users routines is about getting closer to the real problem domain experts and develop empathy. They are who define the success of your product because they feel the pain you are trying to solve.

If you are really concerned to deliver value and make an impact on your end-users, sit on their side, and hear what they have to say. Work with them. Rich insights come from this action and can be a game-changer to success.

Once we have the opportunity to stay weeks validating the very first prototype together with the end-users, in their site. Amazing weeks! It was not easy, but every feedback collected was so valuable to understand their real needs and build the right solution.

Avoid the hype complexities

All those ultimate, shiny, killer framework or architecture on the hype are tempting to use for any tech lovers.

Hypes tend to make us look only after the solution and forget the real problem. When making hype biased trade-offs, there is a high risk to adopt the wrong tool and bring unnecessary complexity to your business.

Technologies and architecture are created to help us solve a problem, not to bring more problems. Stay focused on the real problem to make non-biased and relevant trade-offs. Keep things as simple as you can.


In our development career, when we start leading technical decisions, we need to have a process, so we can make GOOD decision.

Practicing the 4 essential actions in this article helped me not only make good technical decisions, but also be consistently making good decisions.

How about you? Do you lead technical teams? Do you have to make technical decisions for others? I told you mine, but what is YOUR approach to make GOOD decisions consistently? Share with us!

Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git