What is a manager?

A manager is someone responsible for organizing resources, people, priorities, information, and decisions so that a specific outcome can be achieved.

That sounds simple until we remember that none of these things exist in isolation. People have different interests. Departments compete for priorities. Resources are limited. Clients change their minds. Deadlines get compressed. Executives want answers. Technical teams need context. And many of the most important problems appear precisely when there is no perfect solution available.

A large part of a manager's job is knowing how to operate inside this complexity.

A manager does not necessarily need to know every business rule inside a product, every request and response of an API, or every detail of an architecture. That is why companies have business analysts, developers, architects, product specialists, and domain experts.

In the same way, a manager does not need to know why a particular class is failing, which database index is missing, or which UI component should be changed. They need enough context to ask good questions, understand implications, and make informed decisions, but management should not become a competition over who knows the most technical details.

The manager has a different responsibility: helping people with different expertise work toward the same result.

What does a manager do?

When someone asks what does a manager do, one of the best answers I can give is this: a manager creates clarity where there is complexity.

Managers organize activities, priorities, processes, people, and information. They help the team understand what needs to happen, what can wait, and, more importantly, why. They make decisions when trade-offs exist, manage expectations when not everyone can get what they want, and create direction when different people are trying to solve the same problem in incompatible ways.

There is also one responsibility that I believe is frequently underestimated: organizing information.

A developer does not need to receive the same information, at the same level of detail, as a CTO. A client does not need to participate in every technical discussion. An executive probably does not want twenty pages describing every task completed during a Sprint when their actual question is simply whether the delivery is at risk.

A manager needs to understand the context and translate information into something useful for the person who is going to consume it.

That is management too.

The best professional on the team is not necessarily the best manager

This is one of the promotion mistakes I see most often: treating technical performance as if it were the previous level before management.

Do we have the best developer? Make them an Engineering Manager. The best salesperson? Now they manage the sales team. The best analyst? It seems natural to make them responsible for the entire area.

The problem is that what made that person exceptional in their previous role may have very little to do with what they need to do after the promotion.

An excellent developer may spend hours deeply focused on solving complex technical problems. A manager may spend much of the day dealing with people, conflicts, expectations, priorities, meetings, incomplete information, and decisions where there is no technically correct answer.

A great specialist may hate meetings, have no interest in developing other people, and genuinely prefer solving increasingly difficult technical problems. There is absolutely nothing wrong with that.

The mistake is treating management as the only possible destination for someone who wants to continue growing.

When companies do this, they are not necessarily developing managers. They are often turning specialists into managers because their career structure failed to provide a better alternative.

What is the role of a manager?

The role of a manager is not to be the smartest person in the room, and it certainly should not be to have every answer.

In fact, the more responsibility a manager has, the less realistic it becomes to expect them to know every subject under their responsibility in depth.

Imagine a technology executive responsible for engineering, infrastructure, security, data, architecture, vendors, and hundreds of professionals. It would be absurd to expect that person to understand every technology better than all of the specialists working in those areas.

What we should expect is something different: the ability to ask good questions, recognize risks, set priorities, choose between imperfect alternatives, create alignment, and put the right people in a position to solve each problem.

A good manager does not need to be the best specialist in every discipline. They need to know how to make great specialists work together to produce a better result.

The famous soft skills are not very “soft”

I have always found the expression soft skills slightly misleading.

The name makes them sound like optional abilities — nice things to have, but somehow less important than the “real” skills.

Try managing a critical project while two directors completely disagree about priorities. Try telling an important client that their request will not be accepted. Try explaining to an executive that the date they promised is impossible without sacrificing quality or increasing the budget. Try mediating a conflict between two excellent professionals who can no longer work together.

Suddenly those skills do not feel particularly soft.

Some of the most important management skills become visible exactly in these situations:

• Finding a way forward when two parties have argued for too long and the problem has stopped moving.
• Explaining clearly and professionally why a request cannot or should not be accepted.
• Protecting the team from random priorities without losing alignment with the business.
• Saying no to someone above you in the hierarchy when accepting another request would put the entire delivery at risk.
• Turning technical problems into information executives can actually use to make decisions.
• Giving difficult feedback without turning a development conversation into a personal attack.
• Making a decision when none of the alternatives are perfect and accepting responsibility for the consequences.

None of these abilities appear automatically because someone has written code for ten years or understands a product better than anyone else.

They have to be developed.

How to be a good manager

The first thing I would tell someone trying to understand how to be a good manager is to stop believing that management means controlling everything people below you are doing.

The more a manager needs to decide every detail, review every task, and participate in every conversation just to make sure something happens, the less management they are actually doing. They have become a bottleneck.

A good manager creates context, establishes boundaries, distributes authority, and builds mechanisms that allow results to be observed without personally executing everyone else's work.

This requires communication, delegation, decision-making, and trust. It also requires enough maturity to accept that another person may solve a problem differently from how the manager would have solved it.

This transition can be particularly difficult for newly promoted specialists. For years, they were rewarded for having answers and solving problems directly. Suddenly, they need to understand that their success depends less on the answers they personally produce and more on the ability of other people to produce good results.

Does a manager need to understand the team's technical work?

Yes. Technical context helps. In some management roles, it helps enormously.

An Engineering Manager with a software background will probably understand certain engineering decisions faster. A manager with experience in financial services may recognize regulatory risks earlier. Someone who knows the product deeply can discuss trade-offs with much better context.

But there is an enormous difference between having technical knowledge and believing that technical knowledge replaces management capability.

It does not.

Technical expertise can make someone a better manager, but if that person cannot communicate, delegate, prioritize, handle conflict, develop people, say no, or make decisions under uncertainty, knowing more technical details than the team will not solve the problem.

Individual contributor vs manager: two different career paths

This is where I believe many companies create the problem themselves. They treat the transition from individual contributor to manager as if it were simply the next level of the same career.

It is not.

An individual contributor generally creates value through their own expertise and execution. As they become more senior, the problems they solve may become more complex, their decisions may affect more people, and their technical influence may grow significantly.

A manager creates value differently. Much of their impact comes from enabling other people to perform better, making decisions across competing priorities, improving coordination, removing organizational friction, allocating resources, and creating an environment where the team can produce results.

Neither path is inherently better.

They are simply different.

The problem appears when the company tells a great individual contributor, directly or indirectly, that the only way to earn more money, gain more influence, or continue progressing is to stop doing what they are excellent at and start managing people.

That is not career development. In many cases, it is just a poorly designed career structure.

Management also needs data

There is another important point. A manager can have excellent interpersonal skills and still make terrible decisions if they do not have enough visibility into what they are managing.

Knowing how to communicate with stakeholders does not help much if you discover a delay after the deadline has already been missed. Knowing how to negotiate a budget is not enough if nobody can explain how much money the project has consumed. Talking about autonomy is also not very useful if you cannot see when productivity, quality, or predictability start deteriorating.

This is where tools can help.

With Saint Jude Project Intelligence , data that already exists in platforms such as Jira, Azure DevOps, Asana, monday.com, and ClickUp can be transformed into information about schedules, costs, productivity, performance, risks, estimates, task quality, and Sprint behavior.

That does not turn someone into a good manager, and I think this distinction matters.

Data can help a manager identify problems, compare results, and make better decisions. But no platform can decide for them how to communicate bad news, negotiate an impossible priority, or have a difficult conversation with someone who is struggling with performance.

Tools can provide intelligence. Management remains the responsibility of the person who has to interpret that intelligence and decide what to do with it.

Management is a profession

This is probably the central point of this article.

Management is not simply doing the same job you did before while having a few names underneath yours on an organizational chart.

It requires communication, negotiation, emotional intelligence, prioritization, decision-making, delegation, the ability to develop people, and the ability to create clarity in situations where complete information is rarely available.

All of these things can be learned, but they actually have to be learned.

There are courses, books, mentors, frameworks, management training programs, and entire academic programs dedicated to these subjects. And, just like any other profession, there is also a large part that can only be learned through real experience.

What makes no sense is believing that someone can be an excellent technical specialist on Friday, receive a new title in the HR system, and somehow arrive on Monday already knowing how to hire, fire, delegate, give feedback, negotiate budgets, handle conflict, and develop a team.

The title changed overnight. The capability did not.

Not every great professional should become a manager

Maybe one of the best ways to solve part of this problem is to stop treating management as the final reward for a successful career.

Some people genuinely want to manage teams. They enjoy developing professionals, making decisions, negotiating priorities, and solving organizational problems. For them, a management career may be exactly the right path.

Other people want to remain specialists. They want to deepen their expertise, solve increasingly complex problems, build architectures, develop products, research, design, or become exceptional in a particular discipline.

Those people should also be able to grow, earn more money, increase their influence, and reach very senior levels without a company placing five direct reports under them simply to justify a promotion.

When companies fail to provide that option, they create a fairly absurd incentive: to continue growing, an excellent specialist has to stop doing exactly what made them excellent.

We need to put managers in management roles

So I return to the sentence that started this article.

We need people who are prepared to manage in management roles.

This does not mean a developer cannot become an excellent manager. They can. So can a designer, business analyst, salesperson, architect, or any other specialist.

But the promotion should not happen simply because that person was the strongest individual contributor on the team.

It should happen because they want that career path, demonstrate potential for the role, and are willing to develop the capabilities required to perform a profession that is different from the one they performed before.

Management is not a prize, and it should not be treated as the mandatory next level of professional seniority.

If you want to manage, learn how to manage. And if your company needs a manager, look for someone who is prepared to do management — not simply the most technically capable person on the team.

What do you think? In your company, can great individual contributors continue growing without moving into management, or do they still need to become managers to progress professionally?

See you soon!

Erik Scaranello