Mastering the Art of Surrender: A Developer's Guide to Power
Written on
Chapter 1: The Power of Perceived Weakness
"When the monarch passes, the attendants bow low and release a silent fart." - Ethiopian Proverb.
In the world of software development, it often feels like developers are mere puppets, responding to the whims of leadership and project timelines. Many developers may believe they lack control; when successes occur, others take the accolades, while they bear the brunt of delays. However, weakness can be a strategic asset, especially when decision-making carries the burden of responsibility.
Law 22: Utilize the surrender tactic: convert weakness into strength.
Those who crave recognition may fall prey to the surrender tactic.
“When you find yourself in a weaker position, don't engage in a futile struggle for accolades; opt for surrender instead. This approach grants you time to recuperate, to vex your conqueror, and to bide your time until their influence wanes. Deny them the satisfaction of defeating you—surrender first. By turning the other cheek, you provoke and unsettle them. Use surrender as a tool for empowerment.” - Robert Greene
What does it truly mean to surrender? Why would one choose this path?
“If you find yourself temporarily outmatched, the surrender tactic serves as an excellent means to regain your footing — it disguises your ambitions, cultivates patience and self-discipline, both crucial skills in the game, and positions you favorably to exploit your adversary's eventual decline.” - Robert Greene
When you’re at a disadvantage, fighting is futile and can deplete your resources. It’s essential not to engage in battles dictated by the opposition.
Instead of fighting a battle you cannot win, consider surrendering and concealing your strength. Surrender can disarm your adversary, allowing you precious time to regroup and strategize.
Surrendering requires self-control, patience, and a long-term vision. It may be wiser to concede a battle but ultimately secure victory in the war.
Section 1.1: Surrendering as a Developer
In the television series "The Sopranos," Tony Soprano feels the weight of being second-in-command. Eventually, he recognizes that the leader bears all the grievances and chaos. Leaders are burdened with making tough decisions, accepting accountability when projects falter.
For developers, the frustration mounts when projects are laden with unrealistic expectations and additional requirements. The same deadlines that pressure developers are often the ones that lead leaders to falter.
Developers may not make decisions, but they contribute to planning without ownership. It’s crucial for developers to yield to these plans; when things go awry, it’s not solely their fault.
When new requirements emerge, and a manager attempts to incorporate them into an already full sprint, calmly redirect the request. Pose an open-ended question:
“How can we integrate that additional development when our sprint is already at capacity?”
No one enjoys being directed; they prefer to solve problems independently. This enables the manager to relay to the client that the request is unfeasible.
The video title is "I Fart In Your General Direction! - YouTube". This humorous take highlights the dynamics of power and surrender in a light-hearted manner.
When a great manager steps away, the wise developer bows respectfully and maintains discretion.
This Ethiopian proverb reflects the reality that managers often seek validation, and it’s beneficial to publicly acknowledge their importance, even if you don’t personally agree.
Let them assume the role of leader, responsible for delivering unwelcome news and making tough choices. They carry the burden, while developers can focus on their craft.
Like Tony Soprano, it’s often more advantageous to orchestrate events from behind the scenes. Developers should allow managers, clients, and leaders to handle crisis meetings and project re-evaluations.
In the larger context of software projects, meetings often become noise. When you consider the entire timeline, minor delays, such as a week in a year-long project, become insignificant.
Most software project delays stem from underestimations and a lack of comprehensive requirement gathering.
Section 1.2: Long-Term Strategies for Developers
Developers should yield to their managers, project managers, or clients, allowing them to formulate plans. Let the significant figures attend meetings while the development team concentrates on building the software.
Managers are the ones facing emergencies, dealing with anxious clients and dissatisfaction. Allow them to earn their keep.
Developers should adopt a long-term mindset, resisting project-related emotions and adhering to logic and rationality. Aggression, complaints, and drama yield little benefit.
Present facts, outline options with recommendations, and empower leadership to make the final decisions. Those who make decisions are also responsible for the outcomes.
Section 2: The Importance of Being Liked
“Enjoy Yourself (It's Later Than You Think)” - Herb Magidson.
Crafting software is a challenging endeavor, and when problems arise, they inevitably will. While it’s impossible to prevent issues, you can be prepared and recover swiftly.
When setbacks occur, it’s essential to be proactive in communicating this information promptly. Labeling a negative situation diminishes its power and alleviates frustration.
Inform the necessary parties, clarify the cause, and propose solutions. The leadership is equipped to handle the fallout, allowing the development team to return to their work.
Developers should address the obvious challenges and allow leadership to manage them. If the project plan seems unrealistic, voice your concerns and let them handle the situation.
Clever development teams leverage their perceived weaknesses to prompt managers and leaders to make decisions. Developers offer advice; leadership decides. The advantage of refraining from decision-making is the avoidance of accountability.
Section 3: Avoiding Energy Drain
Engaging in disputes with management, voicing complaints, and harboring resentment is a squandered effort that developers could better allocate toward development.
Not only is this unproductive, but it’s also unlikely to persuade leadership to see reason. Instead of resisting, it’s more effective to provide choices and allow them to decide. The individual speaking isn’t the one steering the conversation; it’s the one posing the questions.
Assist with advice, clarify through inquiries, but ultimately allow leadership to take the reins.
Creating software is a creative process. Developers need to focus their energy on actual software development, not on meetings.
Conclusion: Embracing the Developer's Journey
It can be exasperating to be a developer, as it often feels like leadership complicates the software creation process rather than simplifying it. Emotional decisions driven by the need to meet unrealistic project plans can lead to chaos.
Developers and their teams must remain composed while others get swept up in the frenzy, meetings, and distractions of software projects. Allow them to feel significant, make tough calls, and face the repercussions of failed plans.
When influential leaders depart, wise developers bow respectfully and maintain discretion.