Servant Leadership for Engineering Managers: Leading Without Commanding

Robert Greenleaf, who coined the term in his 1970 essay The Servant as Leader, proposed a test that still works better than any leadership competency framework. Look at the people you lead and ask whether they are growing: becoming wiser, more capable, more autonomous. The Greenleaf Center keeps that question at the center of the idea, and it translates to engineering with almost no adjustment. After six months under you, do your engineers make more decisions on their own, or do they wait for you at every fork? That question is the core of servant leadership for engineering managers.

The research behind servant leadership is less settled than the popularity of the term suggests. Dirk van Dierendonck’s 2011 review in the Journal of Management found the field held back by inconsistent definitions and measures, and noted that it overlaps considerably with other approaches such as transformational leadership. That is a reason to treat it as a useful stance with practical habits attached, not as a proven formula.

That question exposes a common trap. A strong engineer gets promoted, keeps being the best architect in the room, and within a month the team goes quiet. Engineers wait for instructions, escalate small calls, and argue less in design reviews. Nobody chose this. It happened because the manager’s answers were always the fastest route to a decision, so the team stopped producing its own.

Four Ways Engineering Managers Misread Servant Leadership

Servant leadership has a soft-sounding name, and that invites misreadings. The PMBOK Guide lists it among recognized leadership styles alongside transactional and transformational leadership, and agile frameworks build it into roles like the Scrum Master. None of those sources describe a leader who avoids authority.

The third row catches the most new managers. Picking up tickets feels productive and keeps your technical skills sharp. It also takes the most interesting work away from the people who need it to grow, and it makes you the bottleneck on delivery as well as decisions.

You Still Have to Manage

John Kotter’s Harvard Business Review article “What Leaders Really Do” draws a distinction that helps here. Management copes with complexity: planning and budgeting, organizing and staffing, controlling and problem-solving. Leadership copes with change: setting direction, aligning people, motivating them. Organizations need both, and so does your team.

A manager who embraces the serving half and neglects the managing half leaves the team exposed. Headcount requests, budget cycles, and escalations to other teams do not wait for philosophy. The 7th edition of the PMBOK Guide reflects the same balance: “demonstrate leadership behaviors” is one of its principles, and servant leadership is presented as one style a leader adapts, not a replacement for running the project.

A useful test is the direction of travel. When a problem appears, a commanding manager pulls the decision up to themselves and hands an answer back down. A serving manager pulls the problem into view, adds the context the team was missing, and hands the authority back down to whoever is closest to the work. If you find yourself making choices the team could have made, you have become the constraint on its speed.

Run Impediments Like an Incident Queue

“Serve the team” sounds abstract until you give it a queue. The Scrum Guide describes the Scrum Master as serving the team partly by “causing the removal of impediments”, and the wording matters: causing the removal, not personally removing every one. That is the right model for an engineering manager too.

Every team produces a steady stream of blockers: a flaky pipeline that eats a day a week, a security review stuck for two sprints, a missing API contract from the platform team. Left informal, they live in sighs and side conversations. Put them in a queue with owners and dates, and they become solvable.

IMPEDIMENT QUEUE
Columns: Impediment | Raised by | Date raised | Work blocked | Owner | Status

Rules
1. Anyone can add an item in the team channel. One line, no ticket needed.
2. The manager owns the queue, not every item. Cross-team items get a named
   owner from the team where that builds their relationships and skills.
3. Review the queue for ten minutes once a week, in front of the team.
4. Anything open longer than two weeks gets escalated by the manager, in writing.

Rule two is where serving and growing meet. Some items are yours because only you have the access. Others are better handled by an engineer who will learn from negotiating with another team. For those, your job is to make the introduction and back them up. The techniques in how to lead engineers without authority are worth sharing with whoever takes them on.

Rule three is what builds trust. A team that watches blockers get cleared week after week starts raising them earlier, which is exactly the behavior you want.

When the Impediment Is Another Team

Some impediments do not clear, however often you escalate them. In one role, my development team sat at the end of the delivery funnel, after design. Our delivery dates were fixed, but the design team rarely treated its part as urgent or closed it within the agreed time. The delays landed on us, and because leadership did not always look deeper, my team was sometimes blamed for delays that started upstream.

I raised it repeatedly, including in retrospectives, and nothing changed on the design side. At that point, serving my team meant removing the dependency rather than waiting for someone else to fix it. I led the team in building an AI-based solution that could produce the design assets we needed on our own, and it covered about 99% of our needs without waiting on the design team. Our blockers dropped sharply and our delivery turnaround improved dramatically.

It was a decision I made rather than delegated, because no one on the team had the standing to change how we depended on another team. Removing that dependency was the most useful thing I could do for them.

What a Serving Manager’s Week Looks Like

The philosophy becomes real in how you spend your calendar. A practical week might look like this:

• Monday: review the impediment queue and pick the two items only you can unblock. Share the week’s priorities and, more importantly, the reasons behind them.
• Tuesday: one-to-ones focused on growth rather than status. Ask what each person wants to learn next and what is getting in their way.
• Wednesday: stay out of the design review, or attend and speak last. Your opinion spoken first becomes the answer.
• Thursday: cross-team work: escalations, dependency negotiations, and context-gathering the team cannot do from where they sit.
• Friday: audit your own calendar. Cancel or delegate any meeting that exists mainly because you attend it.

The Wednesday habit is the hardest for technically strong managers. Speaking last lets the team practice reasoning in public, and it lets you hear what they actually think before your view reshapes the discussion.

Deciding Is Part of Serving

Delegating by default still leaves decisions that belong to you. The question is which ones. Four situations cover most cases:

Decisions that change the team’s working agreements are a special case. Bring those to the team as proposals, because agreements made with people hold far better than agreements made for them.

Whatever you decide, say why. Overruling someone does not damage trust nearly as much as overruling them without explanation. The clearest sign the balance is right is slightly uncomfortable: the team makes good decisions while you are on holiday. The other leading teams guides cover the related skills of influence, motivation, and accountability.

Two Calls: When to Step In and When to Stay Out

The table above is easy to agree with in the abstract. Here is how it plays out on two decisions in the same month.

Stepping in. Two senior engineers have argued for three weeks about the datastore for a new service. One wants PostgreSQL, the team’s existing strength. The other wants a managed key-value store that scales without tuning. Both positions are reasonable, design work has stalled, and the launch date is fixed by a customer contract. Delegating further would not be service; it would be leaving the team stuck. The manager sets a 48-hour deadline for each engineer to write a one-page case covering expected load, operational cost, and team familiarity. Then the manager decides (PostgreSQL, because the team can operate it confidently on day one and the projected load is well within its limits), explains the reasoning in writing, records the other engineer’s concerns, and agrees a load-test milestone at which the choice will be revisited if the numbers look wrong.

Staying out. The same month, the team debates naming conventions for a new internal API. The manager has a clear preference and could settle it in one message. It would be faster. But the choice is reversible, the team has all the context it needs, and settling it would teach them to wait for the manager on the next small call. The manager stays out of the thread, and the team picks a convention the manager would not have chosen. That is the right outcome.

The difference between the two was not how strongly the manager felt. It was whether the team could resolve it, whether delay had a real cost, and whether the decision could be undone.

Signs the Model Has Gone Wrong

The team has become dependent. If engineers no longer decide anything because you always have, you are not serving them; you are making them less capable. The fix is clearer ownership, covered in accountability without micromanaging.

Service has become conflict avoidance. Serving someone’s growth sometimes requires an uncomfortable conversation. Skipping it to stay liked is the opposite of the model. The scripts in how to give difficult feedback to engineers help with exactly that.

You are applying it during a crisis. In a production incident, one person makes calls and everyone else executes. The service the team needs in that moment is speed and clarity, not consultation. Return to the serving posture once the incident is resolved.

FAQ

What is servant leadership for engineering managers?

A leadership approach, first described by Robert Greenleaf in 1970, in which the leader’s main job is the growth of the team and the success of the mission. In engineering it shows up as removing impediments, sharing context, and delegating real decisions. The measure is whether engineers become more autonomous over time.

Does servant leadership mean never making decisions?

No. Servant leaders still decide when a choice is irreversible, regulatory, or deadlocked, and they explain their reasoning. What they avoid is making decisions the team is better placed to make. Withholding every decision just hands your uncertainty to the team.

How is servant leadership different from management?

Management handles complexity through planning, staffing, and control; leadership handles change through direction and alignment. Servant leadership is a way of exercising authority inside the management job, not an alternative to doing that job. You still own budgets, staffing, and escalations.

How do I start servant leadership as a new engineering manager?

Servant leadership for engineering managers starts small. Start an impediment queue this week and review it publicly every week. Pick one decision you would normally make and hand it to the engineer closest to the work, with the context they need. In design reviews, speak last. Repeat for a month and watch how decisions start to move.

Last updated on 10 October 2026