“Can we test it this way on integration environment?”
It was not a difficult question. That was exactly the problem.
The integration environment was something the team managed themselves. There was no architectural risk or serious business impact. I did not need to decide how they should use it.
But questions like this kept appearing. Not this exact question, but similar ones.
Permissions. Testing. Small technical decisions. Things that, in my head, clearly belonged to the team.
At some point I started thinking:
Why are they asking me this?
It took me longer to ask the more uncomfortable question:
Why have they learned that they should?
I delegated the work. I kept the decisions.
I was already careful about taking too many development tasks.
As an Engineering Manager, I know my calendar is unpredictable. Incidents happen. Someone needs help. A stakeholder meeting appears. A people topic suddenly becomes more important.
So when I code, I usually choose work that is independent and does not put me on the team’s critical path.
I thought that protected me from becoming a bottleneck.
It didn’t.
The bottleneck was not tasks. It was decisions.
The team could own the implementation, while uncertainty still had a tendency to travel upward.
- How should we test it?
- When should we deploy?
- Which option should we choose?
- Can we do it this way?
Each question was small. But each one required me to stop what I was doing, recover some context, think about the problem, make a decision, and then return to whatever I had been doing before.
The cost was not the minute required to answer. It was the repeated context switching.
There was a second cost that was less visible: every decision I made was a decision somebody else did not get to practice making.
That matters when you expect engineers to become more independent over time. I cannot set a high bar for technical judgment and then keep taking away the opportunities to exercise that judgment.
Being useful trained the team to wait
I usually have an opinion.
Not necessarily the right one. I am comfortable saying that I am not sure and thinking aloud. I like putting an idea on the table so that someone can challenge it and we can make it better together.
That can be useful.
But I started noticing what happened in technical discussions.
I would introduce a problem and ask:
“How should we solve this?”
Then there would be silence.
I would wait, but probably not long enough. I don’t particularly enjoy long pauses in meetings, so I would start explaining how I was thinking about the problem.
Then someone reacted to my idea. Another person added something. The discussion started moving.
It felt productive.
But if this happens often enough, the team learns something: they don’t really need to create the starting point. If they wait a little, I probably will.
That changed how I interpreted the increasing number of questions coming to me.
Maybe people did not lack ideas. Maybe I had made it unnecessarily easy not to use them.
The loop was simple:
The real warning sign was not my inbox. It was seeing too little initiative when we actually needed ideas.
I had become the fastest path to an answer.
And that had made me the bottleneck.
I had to change how I answered
The first change was almost trivial.
Instead of answering a question, I started asking:
“What do you think?”
Most of the time, people had an answer.
For larger problems, I sometimes ask them to come back with one, two, or three possible approaches before we discuss it.
That changes the conversation. I can still challenge the proposal, point out a risk, or add another perspective, but I no longer need to generate the first solution.
I also started giving decisions away more explicitly.
“This is on your side.”
“You decide how you want to test it.”
“You decide when to deploy it.”
Some of those decisions were uncomfortable at first because I, or another experienced person, had handled them before.
But that discomfort is part of gaining experience.
If I keep doing something because I can do it faster, nobody else gets the opportunity to become faster at it.
The harder change for me was learning to tolerate silence.
When I ask a question now, I try to wait longer before saying what I think. Silence in a meeting can feel unproductive, but sometimes it is simply someone thinking.
If I fill that space immediately, I might save ten seconds and lose somebody else’s idea.
With quieter people I still sometimes ask directly:
“What do you think?”
But there is an important difference between inviting someone into the discussion and supplying the answer for them.
I also had to stop routing communication through myself
We used to have daily stand-ups. Over time they often became status meetings:
“I did this.”
“I am doing that.”
“No blockers.”
Most of that information was already visible on our Azure DevOps board, while the meeting interrupted one of the most productive parts of my day.
So I reduced my attendance at shared stand-ups to twice a week.
When introducing the change, I made one thing explicit: do not wait for the next stand-up. If you have a blocker, contact whoever can help immediately.
Another developer. An owner. Me. Whoever is needed.
One team occasionally created its own technical stand-up. Another decided it did not need one. I left that choice to them.
What mattered to me was that communication started happening more directly between the people involved instead of waiting for a manager-led meeting.
The goal was not less communication. It was less communication routed through me.
A later three-week vacation became an unplanned test of the same idea.
I left, and the teams kept working. They made decisions and things moved.
That does not prove that a manager is unnecessary. It confirms something much simpler: many decisions that used to reach me never required me in the first place.
Ownership does not mean leaving people alone
There is an obvious way to take this too far.
A manager can respond to everything with:
“It’s your decision.”
And disengage.
That is not ownership.
I still get involved.
For important architectural decisions, I want another pair of eyes on the proposal. Sometimes that is me, sometimes our architect. For priorities, I may explicitly decide that one project matters more than another or that maintenance work needs to wait.
I also step in when the trade-off starts affecting scope, delivery time, or cost in a meaningful way.
I do not have a formal rule for which decisions should come to me. My default is that if a decision is local to the team, reversible, and the options have a similar cost, the team should make it.
If one technical option takes a day and another takes a week, I want us to discuss that trade-off. If a decision affects scope or a delivery commitment, I want the team to come with concrete options so we can decide what to cut or what to move.
For decisions with a large technical impact, the right person may be our architect rather than me.
Even then, I would rather start with the team’s proposal than make the decision for them.
What changed is that I no longer want the team to begin every uncertain situation by asking what I want them to do.
The distinction I care about is not whether the manager is involved.
It is whether the team owns the decision or is waiting for the manager to make it.
I still like solving problems. I still enjoy going deep into technical topics. Sometimes getting deeply involved is exactly what the situation requires.
The mistake was not being technical or having opinions.
The mistake was making myself the default path through uncertainty.
If I always provide the answer, people learn to ask me. If I always fill the silence, people learn to wait.
And if I delegate execution while decisions still have to travel upward, I have not delegated as much as I think.
So I now pay attention to a different signal:
How many decisions need me before they can move?
A team can have perfectly distributed tasks and still depend on one person.
Real ownership starts when the work can keep moving, and good decisions can still be made, when that person is not in the room.