- Published on
Be nimble, move fast, when you can
- Authors
😎
- Name
- Mario Adisurya
Speed is critical to business success, where delivering too slowly can result in a business losing its competitive edge. Some of the most successful people I’ve worked with, the ones who you just know can thrive in any business, all have this one particular characteristic (or skill?): to be able to discriminate and know when one can move fast and when one can’t, and isn’t afraid to face uncertainty head-on and move fast when they can.
I believe that this is attributed to having a strong culture that embraces iteration and continuous improvement. Below, I share some of my perspectives on areas you can focus on to foster and strengthen iteration and continuous improvement in your company culture.
Dissent > Consensus
Peter Goodman wrote an excellent blog post on the idea of “building momentum and farming for dissent”, drawing inspiration from Netflix’s “Informed Captain” and Amazon’s “bias for action” and “disagree and commit” cultures
As teams and headcount grow, the number of people with differing perspectives and opinions will potentially grow as well. The next thing you know, it takes days, weeks, or even months for decisions to be made due to more time spent on discussions and debates without everyone involved being able to come to an agreement
The suggestion here is instead of making full consensus your goal, start “farming for dissent” instead. Get others with differing perspectives or opinions to engage in constructive discussions in your proposal—once there’s enough information and clarity to make an informed decision, commit to it
I also love how GitLab articulates and expresses this concept in their company handbook:
…collaboration is not consensus and disagreement is part of collaboration
…You don’t need to have everyone agreeing to the same thing - they can disagree, commit, and disagree. Two-way doors decisions can be reversed as part of disagree, commit, and disagree, while one-way door decisions benefit from more input. We believe in permissionless innovation—you don’t need to involve people, but everyone can contribute. This is core to how we iterate, since we want smaller teams moving quickly rather than large teams achieving consensus slowly.
Build autonomy with transparency and psychological safety
The main point I’m trying to express here is when contributors in your team or organization are empowered and have the right information and means to work autonomously, they’ll be able to more frequently maintain the momentum of their work and deliver faster as a result since they won’t be blocked by inconveniences such as waiting for someone to respond to their slack message or wait for IT to give them access to some cloud resource
As a fully remote company, one of the key drivers that Posthog uses to foster and strengthen autonomy is transparency:
Transparency enables everyone to know what is going on with the company without synchronous communication. This creates autonomy and empowerment.
Another strong driver for autonomy, in my opinion, is psychological safety. The whole point of being able to work autonomously is that you don’t need constant guidance or hand-holding to get things done, and having a culture that punishes you for taking risks or ridicules you for getting things wrong produces a lack of confidence in individuals as well as incentivizes individuals to diffuse responsibility for their work and decisions.
Google recently did some research into answering the question: “What sets apart effective teams from the rest?” and Addy Osmani kindly authored a post summarizing their findings. What Google found was that “how teams work together matters more than who is on the team”, where psychological safety scored as the highest characteristic of an effective team.
High psychological safety enables individuals to propose innovative solutions or admit errors without fear, fostering an environment ripe for growth and learning.
In short: autonomy requires confidence in taking ownership of your work, and confidence in taking ownership of your work is a byproduct of psychological safety.
Bias for action and taking calculated risks
“We can’t start project A because we haven’t validated XYZ assumptions”
“We can’t progress with project B because we still don’t have enough clarity on X”
Don’t get me wrong, I’m not advocating that from this point onwards, everyone should start taking action without any sort of upfront planning or design. But based on experience, over-planning is very much a real thing. My general rule of thumb is once your plan/design has enough clarity to make a decision and execute—bias for action instead of wasting time and effort debating over the small stuff or the “unknowns”.
“Many decisions and actions are reversible and do not need extensive study.”, and nothing is stopping you from changing a decision or action that’s already been committed to. If you’re blocked, sometimes the most effective and efficient way to unblock yourself is to:
→ Attempt to implement or apply a decision
→ Fail (if you’re not successful)
→ Apply your learning(s) from the failure to your next attempt
→ Rinse and repeat until you’re successful
Meta is a great example of this, where the concept of “bias for action” is materialized by one of their early mantras: “code wins arguments”—which played a major role in why they were able to deliver Threads so quickly. Instead of debating for days on whether a feature or solution would work, they would instead invest the time and effort into prototyping, experimenting, and testing internally to validate and get feedback quickly until they landed on the best version.
At the end of the day, you need to deliver, and deliver on time—and slowing down to have the perfect plan/idea/solution will only hinder your progression.
Yes, but…
It’s worth stressing that these suggestions should be applied deliberately and pragmatically. If you need to make a risky change that can have substantial and compounding effects on many downstream dependencies, where there might be potential repercussions that are very difficult to reverse—then perhaps it’s sensible to spend a bit more time gathering more clarity and feedback, and being more cautious when committing to a decision and executing.
GitLab calls this two-way door vs one-way door decisions, where we should be judicious in discriminating between decisions that are easily reversible (two-way door) and decisions that are not so easily reversible (one-way door). Again, it all depends on your context.
Sources: