The Job Changes When You Stop Being the Person With the Answer

Earlier in my career, management had been much closer to the craft. At Netwise, I established and led a Systems Analysis function of six analysts. I knew the discipline well, so I could stay involved in recruiting, onboarding, methodology, professional development and quality while still understanding much of the work directly.

The analysts were running different projects, and we had a recurring professional forum where they could bring problems, compare approaches, share ideas and learn from one another. It also created a team around work that otherwise happened separately, while allowing professional development to come from peers as well as from me. At that scale, direct involvement was still practical.

My next role at Amdocs started to stretch that model. I led the business-delivery side of an internal IT organization while Development had separate leadership. The two sides had different responsibilities but shared delivery, so priorities and dependencies often had to be worked through across the boundary.

Later, Development and business delivery were brought together under me, expanding my responsibility across both sides of that boundary.

I wanted the team leaders to have real room to lead. Before that could work, I needed a clearer picture of what each team was responsible for.

I spent time with each leader building that picture: what the team owned, what people expected from it, which stakeholders depended on it, where the difficult dependencies were and where pressure tended to accumulate.

We developed that understanding together. The leaders who owned the work were also shaping the picture I had of it.

That gave us a better basis for deciding where I needed to stay involved and where I didn’t. As the picture became clearer, the leaders had more room to make decisions without checking every detail with me, and I had a better sense of which issues genuinely required a wider organizational view.

Regular one-to-ones gave me one view of the organization. A forum for the team leaders gave all of us another.

Some of it was straightforward coordination: what was moving across the teams, where dependencies were forming, where one group needed help from another and which issues were larger than a single team’s scope.

The forum also gave the leaders more visibility into one another’s work. Teams demonstrated what they had built, shared knowledge and recognized good work that might otherwise have stayed inside one group.

A leader can make a perfectly sensible decision for one team and still create difficulty somewhere else. As the leaders understood more of the organization around them, more of those issues could be resolved between them instead of automatically moving upward.

I still needed to understand what was happening, but increasingly that understanding came through leaders who knew both their own teams and more of the organization around them.

There wasn’t one point when the new model suddenly started working. I noticed it gradually in how some of the teams worked across their boundaries.

Relationships that had initially required more active coordination from me became stronger over time. Leaders increasingly worked through dependencies with one another and came to me with options or recommendations rather than only bringing the problem upward.

The teams felt more cohesive, and we continued recruiting and growing. Bringing Development and business delivery under one organization also improved coordination. On large projects, we were able to deliver on time with less friction between the groups.

I don’t attribute those outcomes to a single management choice. Organizations change for many reasons, and the leaders and teams themselves were doing the work.

There were still situations where I needed to go deeper: a decision needed a broader view, an issue crossed team boundaries, or a leader needed more support. Detailed involvement became selective rather than the normal way I stayed connected to the organization.

The increase in headcount was obvious, but the more important change was who I was responsible for developing.

Earlier, much of my value as a manager came from helping practitioners become better at the work.

Now I needed to help team leaders become better at developing their own people, making decisions and coordinating with their peers. Going directly to their teams with answers might solve an immediate problem, but doing that too often would make it harder for those leaders to grow into the role I needed them to play.

My job was increasingly to understand enough of the organization to know whether that leadership layer was working and where it needed help.

I still wanted to know what was happening across the teams. I just no longer expected to learn it by staying close to all of the work myself.

That, more than the headcount, was the change in the job.