In modern software engineering, "servant leadership" is widely accepted as the gold standard for management. Over the years, this industry has learned that our primary job as leaders is to invert the pyramid: unblock the team, foster autonomy, and get out of the way.
But for technical leaders, this idea introduces a unique and uncomfortable friction. While you want nothing more than to empower your developers, at the end of the day you are still the one accountable for the health, stability, and long-term flexibility of your systems. You must ensure that code meets strict security standards, aligns with the broader architectural vision, and avoids crippling technical debt.
When does "getting out of the way" turn into architectural chaos? How do you hold the line on technical rigor without violating the tenets of servant leadership?
The answer lies in mastering the pillar of clarity.
David Marquet, whose Leader-Leader model is a great example of servant leadership in practice, has a view that consists of three main elements. Control, competence, and clarity. In traditional command-and-control management, leaders rely on restrictions and rules designed to dictate behavior. However, in Marquet's framework, competence answers "can this person actually execute well here?". Do they have the technical skill, the training, the experience to make a good decision and act on it? Clarity answers "do they understand why, and what the organization is trying to achieve?" A team can have plenty of one but not the other, and Marquet's point is that giving control (empowerment) without both in place is where things go wrong: too much empowerment can lead to poor decisions and misaligned activity.
So to focus on the pillar of clarity again, providing absolute clarity on an approved architectural pattern, a security protocol, or a performance threshold creates a safe, predictable environment for decentralized decision-making. Rather than telling engineers how to build a solution, clarity defines the non-negotiable realities the solution must inhabit. By establishing these boundaries upfront, leaders remove ambiguity and cognitive overload, empowering the team to innovate freely and safely within that space.
The Trap: Confusing "Servant" with "Subservient"
The most common mistake new technical leaders make is equating servant leadership with a complete surrender of authority. In an effort to make developers feel trusted, leaders might step back entirely from technical decisions. But that isn't empowerment. It is abandonment. When teams operate in silos, the absence of architectural clarity inevitably leads to a fragmented ecosystem. This can lead to:
- Security vulnerabilities slipping through because teams prioritize speed over compliance.
- Architectural drift as different teams adopt conflicting frameworks or patterns.
- Operational nightmares emerging when site reliability engineers are forced to support a patchwork of disjointed technologies.
- Uneven Observability as teams have different viewpoints on what is required for monitoring, alerting, and logging.
To make it more concrete, let's look at a specific situation I encountered while working with teams on a monolith. I've helped a number of companies break up their monoliths over the years, and at those places, the monolith had evolved into a barrier to the company's success rather than an enabler. The monoliths had most, if not all, of these problems. High risk of unintended changes due to tight coupling. Long-running and complex regression tests necessary to make sure that didn't happen. Systems too big for anyone to fully understand. Complex business logic buried in stored procedures. Heavy collaboration needed just to get everyone in lockstep for a single change. Custom solutions built for problems the industry already has well-established patterns for. And the need to coordinate releases across the entire monolith.
As a result, in each of these situations, I provided absolute clarity on how we should operate going forward. Avoid tight coupling. Make sure each team can work in isolation. Enable independent deployments. Keep business rules in code, not the database. Use industry-standard patterns, practices, and algorithms whenever possible. And don't build systems too big for any one person to understand.
I establish this clarity because all too often, teams fall back to what they know. They feel too rushed, or too unsure, so they always find a reason to stay on the monolith. I provide this clear boundary to force the new behavior. Now, we can always have a discussion for a specific situation and override the standard together, but the goal of establishing this clarity upfront is to drive the day-to-day change of behavior.
With that in mind, one time a team I was working with was building some new integrations, UIs, and workflows for part of their site. Historically, all of that was done in massive stored procedures in an old monolith. To make matters worse, some of those stored procedures would call out to third party web services to send and receive data. I know, crazy, right? This idea was brought up someplace I was working 15 years ago, and even then we said no way, that's just not a good idea.
That architecture was a huge problem in building new functionality quickly and easily. We knew it was slowing us down, we knew it wasn't sustainable, we knew it wasn't fault tolerant, and we knew it wasn't capable of the quality that a distributed solution with automated tests as part of the build could be.
So I leaned on the clarity I'd already set, avoid tight coupling, keep business rules in code, follow industry-standard patterns, and worked very closely with the team to help them come up with a better way of doing things. The new solution would move data out of the monolith into a new dedicated data store, move the calls to the third party web service out of the stored procedure, move the UI to a new modern SPA style application, leverage OAuth for security, and shift how it integrated with downstream systems from data replication and ETL to event driven notifications.
All in all, it completely modernized this new work to how software is built today. The team started down that path, but along the way they hit a snag in processing the new events. To prevent tight coupling, the team was going to have the monolith listen to events to get the status of the new process. However, the team struggled to get the monolith listening for the event working properly. The team quickly shifted to using this as an excuse to revert to the old way of doing things. When I asked them what else they considered, they had nothing to say. Essentially, they just threw their hands in the air, saying, "Well, we can't do it this way." Just continue to rebuild things in the massive stored procedures and keep building on what they were doing. That's the way they knew. It was the way they were familiar with, and they knew they could get around the problem that way.
This violated the architectural clarity we had agreed upon. The team had been empowered to go in any direction they wanted to resolve this situation, as long as they operated within the clear boundaries we had established, but they chose a direction that abandoned them.
A new technical leader, trying to help the engineers feel empowered, might be inclined to say, "Oh well, we'll try again next time," but that isn't leading, that is deferring. As one architect said to me years ago, "Artie, as an architect you have to set standards, and then the hard part starts. Then you have to hold people to those standards. Otherwise what the hell are we doing?"
With that in mind, I had to step in and redirect the team back to the off-monolith solution. Was the snag they had hit really insurmountable? What would need to be true for it to actually work? Was that possible? Could we find another way that still fell within the enabling boundaries? The team quickly realized the snag actually wasn't that bad, and it wasn't insurmountable. A clean, elegant solution within the new framework was possible. Rather than have the monolith listen for the event directly, an off-monolith listener, owned by the monolith team, could look for the event and directly push what it needed to the monolith. The new solution was very quick and easy to do, and it actually saved a lot of work by doing it this way. Their attempt to revert to the stored procedure based solution just perpetuated the problems in the original monolith. The team wanted to keep working on the monolith, but that would violate the clear parameters we had set.
4 Strategies for Establishing Technical Clarity
You do not have to choose between being a supportive leader and maintaining technical rigor. The solution lies in providing clarity that enables rather than restricts.
1. Design for Clarity (The "Paved Road")
Technical standards should not be brick walls at the end of the development cycle; they should be well-paved roads that naturally guide the team toward the right architectural decisions.
- Provide templates, internal platforms, and baseline architectures that already bake in security and compliance.
- Teams should have the autonomy to choose an alternative route if a specific problem demands it, but the enabling clarity of the paved road should be so seamless and frictionless that they choose to use it 90% of the time.
2. Automate Clarity Through Systems
Nothing damages the dynamic between a servant leader and their team faster than the leader constantly acting as an auditor during architecture or code reviews.
- Offload as much compliance as possible to automated systems.
- Use robust CI/CD pipelines, static code analysis, and automated security scanning. Whether leveraging AI tools to accelerate modernization or traditional linters to catch deprecated libraries, let the system point out the missing unit tests. This allows you to stand with the developer to solve the problem, rather than standing against them as an enforcer.
3. Provide Clarity on the "Why"
When a standard must be introduced or reinforced, the conversation must be rooted in context. A traditional dictator says, "Do it this way because it is the standard." A servant leader says, "Here is exactly how we need to operate going forward as we transition off the monolith, because we need our data to scale securely over the next three quarters."
- Tie technical parameters directly to your explicit sprint milestones and functional demonstrations.
- When developers understand how this clarity facilitates structured, incremental delivery across the broader ecosystem, they embrace it as a necessary engineering alignment rather than an arbitrary rule.
4. Democratize Clarity
Technical vision should not be a top-down mandate owned solely by leadership. Cultivate a culture where the team defines and holds itself accountable to these parameters.
- Implement Architecture Decision Records (ADRs) and Requests for Comments (RFCs) to democratize the creation of new standards.
- Encourage cross-team code reviews and guilds to maintain alignment collaboratively. When engineers define the architectural clarity together, enforcement becomes a shared responsibility.
The Bottom Line
Balancing servant leadership with technical excellence requires shifting your mindset from issuing commands to providing systemic and architectural clarity.
Your job is not to dictate every keystroke. Your job is to define the technical parameters clearly, ensure the resulting environment is secure and scalable, and then empower the team to execute within that space. By automating compliance, building paved roads, and providing deep context, you can foster an engineering culture that is fiercely autonomous while remaining structurally sound.