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 are 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 business real problem
The business is the real problem and should be 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 business 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 their 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, relying 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-user’s routine
Experiencing the end-user’s routines is about getting closer to the real problem domain experts and developing 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, on their site. Amazing weeks! It was not easy, but every piece of feedback collected was so valuable to understand their real needs and building the right solution.
Avoid the hype complexities
All those ultimate, shiny, killer frameworks or architectures on the hype are tempting to use for any tech lovers.
Hypes tend to make us look only after the solution and forget about 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.
Conclusion
In our development career, when we start leading technical decisions, we need to have a process, so we can make GOOD decisions.
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 making GOOD decisions consistently? Share with us!
