Tales from the Trenches: My Personal Journey with Servant Leadership
Servant leadership isn't a buzzword — it's a practice born from watching engineers be treated like a means to an end. Here's how I stumbled into it and what it actually looks like day to day.
Servant leadership is not a new concept. Popularized in the 1970s by Robert K. Greenleaf in his essay "The Servant as Leader," its roots stretch back to ancient times. Greenleaf was passionate about servant leadership and felt the most crucial aspect of being a servant leader was to ensure the leader's priority was to serve the employees instead of lead them. He employed this concept at AT&T for thirty-plus years.
Primary Principles of Servant Leadership
So what are the primary principles of servant leadership? Surprisingly, they lay directly in line with just being a caring coworker who wants to see the individual be happy and grow as a person.
Robert K. Greenleaf defined the 10 principles of servant leadership:
- Listening
- Empathy
- Healing
- Awareness
- Persuasion
- Conceptualization
- Foresight
- Stewardship
- Commitment to the Growth of People
- Building Community
This is where different ideas and definitions begin to emerge. What makes a servant leader and the characteristics that describe them vary depending on who you ask.
How Did I Stumble Into This Leadership Style?
In the last 8 years, I've had the opportunity to run multiple teams of varying sizes across country lines and multiple industry verticals. When I started managing software engineering teams for my first startup, I had minimal management experience.
Over the following two years, I managed multiple engineering teams of different sizes and responsibilities. The most notable recurring sentiment I encountered across all of them was an overwhelming sense among engineers that they were a means to an end. Too many times, I would conduct 1:1s and be told that engineers felt like the company didn't care about them or their families. This was more prevalent at the Senior and Principal levels — though I'd guess junior engineers are often just afraid to rock the boat.
Adding insult to injury, these same people were constantly force-fed the concept that the company was a "family" by upper management. Nothing could be further from the truth in my experience — especially in a startup environment.
This was around the time I learned about servant leadership. What a novel concept: stop telling your team they're "like family" and just treat them like a person. Seems far-fetched. (That's sarcasm.)
My Servant Leadership Style
My style of leadership was born from that time and is based on Greenleaf's original principles — adapted for how I actually manage teams.
My personal tenets for self-evaluation:
- Listen to the engineers
- Have empathy for the struggles each engineer is dealing with daily
- Maintain awareness of the current situations the team finds itself in
- Apply foresight into what makes for a non-toxic workplace
- Practice stewardship of the engineers' concerns and needs
- Commit to growth — both the team's and the individual's
- Build community within the team
That's not to say the remaining principles aren't important. I've adapted the framework to work for how I manage. I work daily to ensure engineers feel heard, have what they need to be effective, and feel valued.
Beyond those seven, there are three more principles I consider just as essential:
- Honesty
- Self-Awareness
- Keep it funny
Honesty
How do you build a successful business without trusting your team? We should be able to trust our teams with knowledge pertaining to the business. Bad quarter and no bonuses? Tell them. Missed key financial goals that could affect the company's longevity? Tell them. You might find that one of them has the idea that solves the problem.
Worst case: someone gets worried and leaves. That's not the end of the world. They have to do what's right for them and their family. Wouldn't you? So why lie — or stay silent — about the current state of things?
Self-Awareness
Self-awareness is key to running effective engineering teams. I know I can figure out anything code-related given enough time. I also know that most of my engineers can run circles around me when it comes to actual code knowledge.
Don't hide that. Learn from them. You can help them grow in areas that are harder for them — interpersonal skills, leadership, communication. It's a system of give and take that benefits everyone.
Keep It Funny
Software engineering is stressful. There will be days spent hunting for the one missing semicolon that's ruined your week. As a servant leader, it's paramount to help your team see the brighter side of the chaos.
Keep it light. Help them laugh at stupid mistakes or rogue semicolons. You can be a funny leader and make sure the work gets done. These are not mutually exclusive.
My Takeaway
What's the outcome of this perspective? Not only does it help you develop a far deeper understanding of your team — it helps you grow as a manager.
My greatest takeaway: "If I take care of my engineers, they will take care of the company." I employ this daily at every level.
In a world that often focuses solely on power and authority — what's the harm in collectively embracing these principles? Why is it so far-fetched to think that the people leading the teams are there for the team, not the other way around?
Keep reading
Crisis is inevitable in software. What separates good leaders from bad ones isn't whether crises happen — it's whether they had a plan, communicated clearly, and learned from it afterward.
Innovation isn't a process you bolt onto a team — it's a culture you build deliberately. Here's how to think about both the operational and interpersonal sides of making it real.
I've been working remotely for 8 years — most of them leading distributed engineering teams. Here's what actually makes remote teams work, beyond the surface-level advice.