I always thought that we needed to learn all of the fundamentals of a topic before taking any action. It was the approach I took as a software engineer. I spent my whole life going down rabbit holes, researching, learning, and coming up with solutions that substantially solved the problem. I was wrong. All I needed was action.
Everything started with how the education system shaped my whole life. It is unimaginable. Each day I come across surprises. How the system teaches you to do homework defines your go-to strategy for implementing projects at work. The communication and decision style of the teacher becomes your default style when you collaborate with your colleagues.
Now, when I think about it, as there are hundreds of different education systems around the world, each one of us has another way of doing things at work.
One of the fundamental differences in education systems is persuasion: application-first or principles-first reasoning. In the application-first approach, people usually learn things while doing it. They quickly make soft decisions about how to do it and start implementing the idea. They learn and iterate on the decision on the way. Action is more important than understanding all principles and fundamentals.
In the principles-first approach, people first try to learn the fundamentals before taking any action. They look from different perspectives and then usually make a concrete decision that is difficult to change.
When people need an extensive study to understand more details about the problem, they usually do it to gain certainty. Being aware of possible flaws, errors, and problems gives them the confidence to make better decisions. This risk-averse approach can be either beneficial or detrimental, depending on where it's used.
Some software projects need everything to be figured out before taking any action. Military systems, railway signaling, control systems, and nuclear reactor software follow a principles-first approach. Usually, these systems have safety-critical properties, or they are difficult to roll back in failures. Understanding the fundamentals and different perspectives are required attributes for these systems.
When I was an intern at a military defense corporation, they were in the middle of a project. The project was planned to be released after 5-6 years. It cannot reach the user before it's correctly and fully working. They had to figure out every detail as the errors could cost human lives.
Besides these kinds of applications, speed has become more critical in the digital and technology age. For example, when we look at Amazon's Leadership Principles, under the Bias for Action, it says, "Many decisions and actions are reversible and do not need extensive study." The nature of being customer-centric and fast brings success to Amazon.
I tend to think of businesses like Amazon as predators such as tigers or jaguars. When a tiger goes hunting, what we see is all planning—looking for the weakest victim in a herd, sneaking slowly, and waiting for a perfect moment. However, what we see is only the result—the result of all previous learning.
When we see a grown tiger hunting, it's only the result of many actions. The tiger learns how to ambush a gazelle by trying countless times in its youth. After trying and taking action and failing and learning, the tiger grows and becomes a great predator. How well a tiger learns decides the success of the tiger. It's a matter of life and death.
The speed of learning from actions is driving both the tiger and Amazon. I thought of learning as researching, digging books and blogs, looking up encyclopedias (joking), and research papers. Although that's one type of learning and an essential one, I needed to take action and learn from the results and users. What pushed Amazon to success should have driven me and should guide you as well.
If you're not working with safety-critical systems, you need to learn to switch between principles-first and applications-first (action) approaches but eventually have to bias towards action because there is no faster way than learning from the users and results.
Perfection vs. Action
Learning something new while doing it is one of the best strategies in modern software development. While coaching software engineers, I've seen that everyone agrees to learn coding with practice regardless of the person's background. People who just read posts and watch videos never learn how to code.
You can also see this strategy in companies: the best onboarding processes focus on getting a person to deliver the first piece of work. People begin to learn about the project by fixing bugs or adding small features, not purely by reading the code.
For a while, I was confusing "bias to action" with "think twice, code once" understanding. The confusion was between having the highest quality of architecture and the code and delivering the software. After learning that the perfect architecture cannot be reached, I started separating these.
You can think twice and create good architecture and still have a bias towards action. Just change how you approach delivering software. Deliver fast over and over and over again.
That's why software engineers have to have both mindsets switching constantly. Use a principles-first approach to think about the architecture and the logic of the code; however, use an applications-first approach while planning the deliveries. Having a bias toward action is a design thinking approach that you can apply during the architecture and system design.
Learning new things by taking action and repeatedly iterating on them helps to understand the flaws instead of guessing them. It's almost unimaginable to be prepared for every potential failure. However, it's possible to overcome many of them as faced. And you know what? Everyone faces many failures. The earlier you face, the fastest you learn.
The famous ceramic story supports quantity over perfection. One professor split the class in half and told half of their students to create as many pots as they could in a term, and the quantity will grade them. The other half of the students would create only one pot but make it perfect. At the end of the term, the students who created many pots had significantly better results. The action supersedes perfection.
In every pot, they had small failures that brought significant learnings. They were able to keep going because with each pot; they also achieved a thing. Tiny wins bring a sense of achievement. The feeling of winning motivates the person and prepares for the next.
How to Bias Toward Action?
Many software teams I had talked to, seen, or heard use Kanban, Scrum, or another iterative process. But often, they fail to align their releases with their iterations. Projects take months before the very first release. Big-bang releases are universal when people are afraid or don't have systems that can quickly roll back in case of failure.
One of the keys is rethinking the chosen path for software delivery during planning. Is the plan you choose the best and fastest way possible to deliver the smallest piece of software? What can you eliminate? Can you create another plan with a more diminutive scope without losing any value? Can you deliver in each iteration?
When you keep the iterations and actions smaller, you also make the errors smaller, and smaller iterations make the errors made in previous iterations visible. That's why the Kanban and Scrum Sprints are focused on delivering the smallest piece and have retrospective meetings. The idea is to celebrate the win and learn from the mistakes. Find the quickest way you will learn your mistakes from users.
Create a pendulum between applications-first and principles-first approaches. Go down the rabbit hole when necessary but take a step back and focus on producing a result over perfection. Don't sacrifice quality for taking action. The balance is the key. If you are designing an architecture, design the architecture to deliver software in multiple iterations, not in a big bang.
Define whose responsibility is what. Who is accountable? When there is a sense of ownership, people take everything seriously. But when there is a loosely defined responsibility, it creates confusion and conflicts. Every action should have a directly responsible individual.
Take care of people. Some people might not be comfortable with the approach you're taking. Listen to them, hear them, and then talk. Acknowledge their concerns and address them as much as possible. However, don't let yourself be carried away by solving all of them. Sometimes take no action by accepting the risk. However, be clear about why you are willing to take the calculated risk.
Bring just enough clarity to the future. Don't plan everything for the next six months—plan the next one to two iterations. Plan the later steps in a high-level overview. Within uncertain situations, people are usually risk-averse and hesitant. Create just enough certainty to lower the stress and keep it at a level where people will be excited to learn and discover together.
Accept, and acknowledge mistakes; own them. When you have action bias over inaction and deep research, you will make many mistakes. Acknowledge them. Don't take a punishing approach. If you are the leader of the team, you're responsible for errors and success. However, don't punish yourself as well. Look to the learning opportunities. Learn from mistakes, and form trust.
Lastly, celebrate. Every small or big win deserves celebration. Getting together with the team and having an informal chat is even enough. You don't always need to plan a big event. But make sure to celebrate success.
These are the strategies I follow. I'm still learning how to create a balance between action and perfection. Having a pendulum between application-first and principle-first is complex and requires constant effort. However, every action requires a step, and I'm willing to put in the effort.
P.S. If you are having struggles with creating a bias towards action, your leaders may need to learn different decision-making styles and influence others using the decision-making pendulum.