Article summary
Like most software developers, I find enjoyment in refactoring code. My aim when refactoring is to simplify and add flexibility to enable future potential. Much like codebases, software projects need to pivot sometimes to unlock future potential. A change at the right time can be crucial for success.
Pivoting is the culmination of recognizing a need, identifying a new direction, and garnering buy-in. It requires strategy, ideation, and execution, making it challenging to pull off. Sometimes you miss the opportunity to pivot. Maybe no reasonable alternatives are found, or stakeholders do not buy in. Additionally, it takes courage to champion the effort since success isn’t guaranteed. Despite these challenges, pivoting remains a promising path forward for a struggling project. Here’s my perspective on what it takes to pivot.
Recognize a need.
I posit that failing to recognize the need is the main reason pivots don’t happen. It can be hard to tell whether action is warranted during the ongoing effort. Sometimes the feeling that a change is needed is met with self-doubt. Other times it may be masked by a sentiment that the team must continue to push through. Senior team members can help surface the need by comparing their experience to a previous project’s experiences. All team members can help sense issues by listening to their gut.
- There’s got to be a better way.
- It feels like we’re moving slowly.
- There’s too much churn.
- Morale isn’t great.
These are things members of a project team may be feeling if their project needs a pivot.
Identify a new direction.
As cliche as it may be, this is the time to think outside the box. It’s incredibly situational but here’s some practical advice:
- Fully understand both the short-term and long-term goals.
This helps keep things in perspective. - Involve the team.
Anyone is capable of proposing a game-changing idea. Additionally, the team won’t be surprised if a change comes to fruition. - Tinker.
Evaluate the merit of promising ideas, even if they seem wacky. - Leverage risk.
For some, the risk will stifle creativity; for others, it will inspire it. Do activities with the team that both suspend and highlight associated risks. - Take tiny bites.
Consider whether the idea must be adopted wholesale or if it can be done incrementally. Incremental adoption can help mitigate risk.
Garner buy-in.
Garnering buy-in is where pivoting will face the most opposition. Advocating for a change is daunting. It requires courage and conviction. Inaction, while valid, is the easy path and can become a potential trap.
Once you recognize a need, you must determine if action is warranted. Action becomes necessary when maintaining the status quo becomes too costly. “Costly” can refer to monetary expenses or more abstract factors like team morale. The reality is that there’s rarely a cheaper time to pivot than the present.
Ideally, stakeholders are already aware some action is needed. However, any potential changes must align with what makes sense for the business. The significance of the pivot and the risk it introduces will determine the difficulty of garnering buy-in.
Acknowledging the risks is critical if you want stakeholders to take you seriously. Highlighting the difference between the scenarios where a pivot occurs and where it doesn’t is essential for gaining support. This is especially helpful for stakeholders who are less involved with the project and may be surprised to hear that the team feels a change is needed. Ultimately, successfully pivoting will require effectively representing the upside and the plan for managing the associated risks.
A Well-Timed Pivot
Pivoting is a variable-risk, variable-reward endeavor that can determine a project’s success. By effectively mitigating potential risk and exploiting the opportunity, pivoting offers a promising path forward for struggling projects. Like refactoring code, a well-timed pivot can unlock future potential and lead to greater success.