Why Distributed Leadership is More Efficient than Command-and-Control
DIAMANTINO ALMEIDAI spent a decade being a professional reminder. It was a relic of a factory age that has no business in a room full of creative engineers.
I'll admit, I spent a decade of my life being a professional reminder.
I thought that was the job. I thought that being a "Senior Leader" meant being the person who watched the clock and checked the boxes. I believed that if I didn’t have my eyes on every line of code and every ticket in the board, the whole ship would sink.
I called it "High Performance." I called it "Maintaining Standards." But if I am honest with you, it was actually just a very polite form of fear.
I was afraid of being irrelevant. I was afraid that if the team could move without me, the company would realize they didn’t need me. So I built a system where I was the bottleneck. I was the center of the wheel. Every decision had to pass through my desk. Every "deliverable" had to have my stamp on it.
I thought I was being a hero. I realize now I was just a wall.
If you are leading a technical team today, you probably feel the weight of the "Metallic Cold." You feel the pressure to move faster. You feel the constant demand for more speed and more output. The industry tells us that the way to get there is through better metrics and tighter control.
But I am here to tell you that the "Foreman" mindset is the least efficient way to build software. Command-and-control leadership is a relic of a factory age that has no business in a room full of creative engineers.
Here is the truth I had to learn the hard way. Distributed leadership isn’t just a "nice" way to treat people. It is the only way to stay human while building something that actually lasts.
The Myth of the Savior
We have a "Hero" problem in tech. We reward the person who stays up until 3:00 AM to fix the production bug. We celebrate the lead who jumps into every PR to "save" the code.
I used to be that person. I loved the rush of being the one with all the answers. I thought my sacrifice was a gift to my team. I thought I was protecting them from the pressure.
But by being the hero, I was actually stealing their growth.
When you lead from a place of control, you create a team of "Users." They wait for your instructions. They wait for your approval. They stop thinking for themselves because they know you will eventually do the thinking for them.
This is incredibly inefficient. It creates a system where the speed of the entire team is limited by the speed of one person's brain. That person is usually tired, stressed, and disconnected from the actual work.
I felt that weight every single morning. I would look at my calendar and see a grid of other people's priorities. I was in debt to my own title. I had become the very thing I hated. I was a manager who didn’t actually know how to build anything anymore.
To fix it, I had to do something terrifying. I had to let go.
Trust is the Ultimate Low-Latency Network
In engineering, we spend a lot of time trying to reduce friction. We optimize our pipelines. We refactor our code. We look for the shortest path between a thought and a deployment.
The greatest source of friction in any team is a lack of trust.
When you have a command-and-control structure, you are introducing a massive amount of latency into every decision. An engineer has an idea. They have to wait for a meeting. They have to explain the idea to a manager who hasn't touched the codebase in months. The manager has to check with another manager.
By the time the idea is approved, the spark is gone. The engineer is just "executing a task" instead of "solving a problem."
Distributed leadership—or what I like to call "Growing a Garden"—is about removing that latency. It is about pushing the power to make decisions down to the people who are actually touching the soil.
When a team owns their own work, they move at a speed that no manager can force. They aren't working to satisfy a metric on a wall. They are working because they care about the ripple effect of what they are building.
Trust is not a soft skill. It is a technical advantage. It is the fuel that allows a team to heal its own gaps. If you have to "enforce" a system, the system is already broken. A good team should be like a forest. It should grow and adapt and sustain itself without a foreman standing over it with a clipboard.
The Soul of the Work
The corporate world tells us that management is about "making things happen."
But if we are honest, it often just means making sure people stay in their seats. We treat the office—even the digital one—like a factory floor. We measure our worth by the length of our feature list. We think that if we move fast enough, we can outrun the feeling that we are just middle-men for an algorithm.
I am sitting here looking at the sunlight on my desk and remembering that I am more than a series of successful deployments. My team is more than a velocity chart.
When you shift to a distributed model, you are finally acknowledging the humanity of the people you lead. You are saying: "I trust your reasoning. I trust your conscience. I trust you to care about the water, not just the ship."
This changes the air in the room. It stops being about "surveillance" and start being about "stewardship."
We are accountable for the ripple effect we create. That ripple effect doesn't just stop at the code. It touches the families of our engineers. It touches the way they feel when they close their laptops at the end of the day.
If your leadership style makes people feel like machines, you are failing them. Even if you hit every date. Even if your "optimization" is perfect. You are failing because you are creating a "Metallic Cold" that will eventually burn everyone out.
How to Start the Refactor
If you are tired of being the hero, you can start the refactor today. It doesn't require a new framework. It doesn't require a change in your Jira settings.
It requires you to be brave enough to say "I don't know."
The next time a team member brings you a problem, don't give them the solution. Even if you have it. Even if you know exactly which file needs to be changed. Instead, ask them a question: "What do you think we should do?"
Then, do the hardest part. Stay quiet.
Let the silence sit in the room. Give them the space to step into their own leadership. You might have to watch them struggle for a moment. You might even have to watch them make a mistake. But that struggle is where the growth happens. That is where a "Resource" becomes a "Partner."
I help tech leaders stop hiding behind their titles and start looking at the water. I believe our job isn't to build machines out of people, but to grow gardens out of teams.
We are the architects of a legacy that goes far beyond software. We are building the culture that our children will eventually work in. Let's make it a culture that breathes. Let's make it a place where the sunlight can reach the floorboards.
Stop measuring the ship. The water is more important.
The Patch: The "I Don't Know" Script
If you want to start sharing the weight of leadership, try this in your next meeting.
When someone asks you for a decision that you usually make alone, say this:
"I have some thoughts, but I'm worried my perspective is too far from the code. I want to trust your intuition on this. What does your gut tell you is the right path forward?"
Then, listen. Don't correct. Don't "optimize." Just listen. You are planting a seed. It will take time to grow, but the fruit is worth the wait.
I write about tech leadership, shared ownership, and staying human in a machine-driven industry. If this resonated, you can find more of my work at newsletter.diamantinoalmeida.com.