6 examples of Bias for action for Software Engineers
Bias for action is a principle that appears in many leadership principle lists of companies, like Amazon. Let us explore what it means and how software engineers apply this principle.
What is Bias for action?
In business, time is money. Many judgments and acts can be reversed and do not need in-depth research. Risk-taking is something that is appreciated.
As software engineers, we have to take risks, decisions and need to judge decisions all the time. This depends of course on seniority and your current level, but in any job as a software engineer - even if you do not work at Amazon - you will show this principle.
The principle can also be described as a calculated risk. Not every decision will be the right one but with a bit of data, you can measure the risk of each option for doing a specific task. If the risk is acceptable you should be open to taking any path that leads to completion of the task, ideally with the lowest friction. If it was wrong, then change.
The characteristics making out a person that fits this leadership principle are consisting of different things. For once, we have the doer. When considering "Bias for action" people that are not scared of doing mistakes will show this leadership principle more. They are willing to do certain things without overthinking. They take the risks required which other people might not take. Additionally, they will also have the courage to own the outcome when taking an action. If the action might lead to failure, they are there to fix it, iterate, improve and maybe iterate based on the action. True ownership.
Which companies use Bias for action?
Next to Amazon there is GitHub who is uses a similar principle called "Ship to learn". It is similar to the details of "Bias for Action" by Amazon. So here is a short list with all the companies using this principle:
With a lot more companies adapting leadership principles "Bias for action" will become more important. Companies also get more technical and analyze the impact they have, making sure that you can pivot from your initial decision if it does not work out. So let us check what software engineers can do in detail to show this leadership principle.
Situations for Bias for action
As a software engineer, you might ask yourself initially where you show bias for action. It is really difficult when you think about it but there are a lot of opportunities and day-to-day activities where you show this principle.
During arguments
A situation where it is quite common to use "Bias for action" is in discussions with the team. It could be any discussion on how to implement a specific feature. Or talking about a past decision on what went wrong. Often, participants in the discussion do not focus on the actions they can take from the discussion but because they like to discuss. In these situations, the leadership principle can be applied. Disagreeing and focusing on actually taking an action, even if you do not agree with it necessarily.
Decisioning Process
As mentioned in the last chapter, most decision processes will be decided based upon discussions. In any way, as software engineers, we will also have the ability to make decisions ourselves. Especially because as a software engineer you will most likely have access to the data to make the decisions. If you know in a meeting that a discussion might help to take any action, but to take a really good decision it will take a bit more time to gather data, delay the decision. The action will be to get more data to make sure whatever action you will take, will make the whole process a success for your customer. To the person or organization, you are writing software for. Push for this principle.
Helping people to make decisions
When you think about discussions, you mostly think about yourself and how you interact in the discussion. But it is also important to put yourself into the other participants' perspective. If you understand the other person and make sure their voice, their concerns, and their decisions are well respected, it is the first step to making good decisions. You can help to convince them of your ideas by giving them a little nudge, to rethink approaches. For example, this works well with gathering data on the problem and presenting it to them. It might make them rethink their decision and take action instead of just arguing with the team.
How do you measure Bias for action?
If you read this article you probably want to know what you have done which relates to this principle. But first, let us check how we can measure Bias for action. It is probably one of the leadership principles that is the most difficult to track. But what you can do is create a brag document every week or month and write down the situations when you took a risk rather than waiting out on deciding something. The more detailed timeline you have of the discussion and decision processes the easier it will get for you to summarize where you acted based on this principle.
Another good tip is to keep a brag document with getworkrecognized and keep records of when you showed a bias for action so you can reference it in the future. With getworkrecgonized, you can keep a diary of all your achievements at work.
Examples of how to apply Bias for action
Programmers show bias for action most of the time by default. But pinpointing specific examples in your career is always feeling difficult. In the following section, we list some examples where bias for action can be shown.
Solutions
Coming up with a solution to solve a problem can be applied to many problems. It can be a technical problem but also a team problem, but we will discover them later in this chapter. In general, solutions should be built minimal. When a problem arises try to focus on thinking of an MVP - a minimum viable product. So to say. A better term would be probably a minimum viable solution that fixes the problem.
Feature Discussions
Discussions about product features are probably the most common one for software engineers to be involved in. For example, it could be a simple discussion of which user interface is better and should be chosen for the next feature. A lot of preferences come into play here like personal experience with UI and experiences at your old company how they have done things. Most of the time an A/B test can help with actually choosing the right UI. Instead of arguing which UI is better, focus on actually choosing a metric that will help you to see which is the better UI.
Another example is purely technical feature discussions. For example, like choosing the right database type for your new application or service. For such decisions, the principle "Bias for action" might not be applied because database migrations are difficult to do in the long term. So you should be still open to listening to other people's opinions but decide on the best long-term solution. Be careful of the risks of your decisions. Note them down.
A different situation can occur during sprint planning with your team. Which feature should you focus on? Normally sprints are taking 2 weeks and there is a goal for the sprint to achieve. People hesitate about what to choose normally and what has the highest impact. Gather data on the impact and effort to finish the different projects, which are also called epics in some companies. With that, you can measure the risk of actually delivering a feature within a sprint and measure the outcome.
Team Issues
Most modern and agile teams follow some sort of sprints. What most of the sprints have in common is a retrospective at the end of each cycle of the sprint. During this meeting, the participants discuss the last cycle and what can be done better. But more importantly, they discuss concrete actions that can improve the team's health and performance. The focus should be on actions rather than discussing the issues. Sometimes though, discussing the issue will clear up specific arguments, so feel free to discuss from time to time, but push the participants of the meeting to take action and remind them that sometimes it is ok to disagree if you have any action and can measure the success in future retros. Especially if the issue is not critical to running your current team's processes.
Mentoring
An engineer will have many opportunities to mentor other employees in the company. More junior people need a helping hand from time to time with easy but also difficult problems. More senior people need guidance on how to navigate the product the best, how to contribute, and what are core parts of the code are.
During mentoring it is important that you can tell the other person that you do not know everything and if you get into a situation where you do not have an answer to a question, you can simply answer you do not know. But it is important to also give them the feeling that if they fail with their actions, failures are appreciated because you can learn from them. This is the most important part. Push them for a decision soon and let them reevaluate if it does not work out. An important part though is to encourage them to also gather some data around their issue, and see if what they thought is right, is working out.
Meetings
The principle can be also shown in meetings. As we learned in the discussions chapter before it is important to take action from a meeting. What you can do to push this action-taking and make it quicker is to just research some data regarding the meeting before the actual meeting. Take 30-60 minutes the next time before a meeting and gather data around the issues that will appear. It will help to drive your meeting forward. And even if the meeting does not go in the direction of actions, take an action to gather data around the issue to see if there is any impact. We also wrote another article on how to structure your meetings.
Documentation
Writing documentation comes short most of the time for developers. A problem that many software engineers have is that they can't put themself into another perspective. So the reader of the documentation will suffer. It is good to create some personas for your documentation and then write the documentation.
It's important to roll out this documentation quickly and gather feedback. Most of the time some documentation is better than none. Take action and write that piece of documentation everyone is needing. For internal customers or external customers.
Summary
Bias for action is a weird leadership principle. It is not clear immediately how this principle is actually manifested in your work and especially in interviews at Amazon, it might be weird to answer this question. Find one of the examples above in your work and prepare them for the interview. And feel free to track your work with getworkrecognized. It will help you to figure out your actions towards "Bias for action".
