The idea of “servant” leaders has been on the rise in the agile community of late. Robert K. Greenleaf coined the term in a 1970 essay, but the idea is timeless. Virtually every religion describes the concept. This one from the Tao Te Ching is particularly poignant:
The highest type of ruler is one of whose existence the people are barely aware.
Next comes one whom they love and praise. Next comes one whom they fear. Next comes one whom they despise and defy.
When you are lacking in faith, Others will be unfaithful to you.
The Sage is self-effacing and scanty of words. When his task is accomplished and things have been completed, All the people say, “We ourselves have achieved it!”
— Lao Tzu
The idea applies to any kind of leader, but I think it’s especially applicable to leaders of software projects, where the unique dynamics of unpredictability and complexity collide.
Ever wonder why software people invent all kinds of alternative labels for “project” (e.g. “Scrum”, “Sprint”, “engagement”, “iteration”, “MVP”, etc) and “project manager” (“Scrum Master”, “Product Owner”, “Product Manager”, “engagement manager”, etc), and everyone else just uses the regular names? It’s not because we’re narcissists who need special labels. It’s because people keep running into difficulty trying to square the very definition of a project (something with “defined scope, schedule and resources") with our real world experiences. In software it’s common to have something estimated at a day take a week instead. Sure, you can call your work a project; you can write down a scope and make a schedule, but it’ll probably be wrong.
The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries. If you’re the CEO of a startup, and you’ve got a fixed technology budget, you don’t want to hear that your software will take up to 4X longer than your team initially estimated.
Because engineering managers inhabit the border between the business and the technical, they are the ones who need to resolve the tension between estimate and reality. It’s a bit like being the wishbone being pulled at both ends; either side can snap. When the business side “wins”, the developers end up in a death march. When development concerns outweigh business ones, you end up blowing the budget and deadline. Either way you’re broken. Successful software managers find ways to be flexible; to bend without breaking and to resolve the tension gradually. Servant leadership can be a guide to finding this flexibility.
What Servant Leadership Means for Software
At its core, servant leadership is about inverting the pyramid of power. Instead of exerting power from the top, servant leaders empower others and enable them from below. Here’s how that looks in software.
Servant leadership works because it motivates people to bring their very best. By being aligned with their innate needs for autonomy, mastery and purpose (see Daniel Pink’s book Drive for more on that), you unlock a completely different kind of engagement in your team. Command and Control may work on some battlefields, but in creative endeavors, blindly following directions is the last thing you want your people to do.
Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? — Robert K. Greenleaf
When considering a project, consider the growth opportunity it represents for each member of your team. Always have an ear trained toward learning what challenges they are ready to take on.
Establish trust with your team by showing you care and looking out for their best interests. Protect them from unreasonable deadlines or unnecessary off-project work. Immediately recognize their achievements. Give them every available tool and advantage to achieve their goals, but do not protect them from the consequences of their own behavior.
Give Developers Control Over Estimation
Developers should estimate their own work, and should be encouraged to be as honest and realistic as possible. Managers shouldn’t “negotiate” with the estimate; that reduces its accuracy and disrespects its creator. Instead, managers should probe for thoroughness in a curious, conversational style that encourages “thinking out loud” about the risks that need to be incorporated into the estimates.
Drive Uncertainty Out of Requirements
Vague or contradictory requirements are the bane of a developer’s existence. Computers are unyielding in their need for precise instructions, and developers spend most of their day talking with them.
To be of service in the early stages of a project, managers need to play an active role in vetting, testing and refining requirements. In the same way a good QA team stretches the software to its limit to ensure it’s not broken, a good manager stretches the requirements to their limit to ensure they’re not broken.
Be “Chief Unblocker”
The best referees are the ones nobody notices because they make the right calls and stay aware of the emotional state of the game to prevent controversial calls from spiraling out of their control. It’s the same for managers and blockers. The best managers see blockers coming and act early to prevent them from ever surfacing. When prevention fails, they act quickly to resolve it, knowing that nothing outranks a blocker.
This requires active listening during stand ups and other meetings. Great managers hone their “blocker radar” by noticing patterns in status reports. When a developer’s standup is nearly identical today as it was yesterday, they notice; the developer might not be blocked yet, but they definitely didn’t achieve yesterday what they expected, and might be at risk of being blocked soon.
Have Empathy for the Customer
Things often take a meandering path between the customer and the programming task. When developers don’t understand the Why behind a request, they can struggle with motivation or even misinterpret the request and build the wrong thing. As the liaison between the team and the customer, the manager needs to excel at understanding the customer better than anyone else. If you don’t understand why a requirement exists… find out. Put yourself in the customers shoes to understand the underlying needs behind their requests.