Not All Developers Are Managers
By: Kevin Fawcett
Tags: Careers, Management, Leadership, Programming, Software Development

An Idea for an Ideal Path

An example career path split into three separate routes (Image source: Author)

Some developers thrive as people managers (team lead), so that path could still be available. People not interested in managing others could still grow their careers with architecture. Finally, those that are interested in climbing the corporate ladder solely for monetary gains have an option to continue doing what they love.

Companies that make the people path the only way forward may have unintended side effects.

Empathy

“[Interpersonal Intelligence] involves effective verbal and nonverbal communication, the ability to note distinctions among others, sensitivity to the moods and temperaments of others, and the ability to entertain multiple perspectives.”—Mark Vital, 9 Types Of Intelligence — Infographic

One-on-one meetings with managers are important for gathering two-way feedback and helping people achieve their personal goals. However, if the manager’s intelligence is logical, not interpersonal, they may struggle to meet their subordinates' needs.

With a dedicated people manager, employees can receive guidance from someone capable of relating emotionally. Empathy is a step toward a happier work environment, which has a positive impact on productivity.

Disabling the team

A good manager enables the team to work more efficiently. However, if a person climbed to that position as a natural next step to a raise, they may not be motivated to give themselves competition.

People managers have a focused role: enable the team. They don’t have to compete with those pursuing technical roles and may not even come from a development background. Having a focused role means:

They can focus on improving their management skills.

They can study individuals and personalities.

They are not overwhelmed with meetings.

Managers with multiple roles may become a burden to the team. They are often overwhelmed with meetings, which can block technical decisions from moving forward. If their work is sporadic and contributes to the team’s velocity, it may artificially boost the representation of what the team can accomplish in a sprint. Even if their development work was not counted, it still takes time to code-review and test. These code changes can sometimes fail to meet the team’s best practices, especially if the managers can’t attend the meetings where the technical decisions change.

Promotion logic

Some people are promoted based on their hiring date, most overtime accrued, or ability to deliver rather than their leadership capability. With the single career path, that may be the best option for retaining talent. However, the result might mean that the strongest performers are no longer coding. Some of them end up leaving for other companies because they miss it.

“There is no more effective way to empower people than to see each person in terms of his or her strengths.” — Don Clifton

The Clifton Strengths assessment focuses on improving strengths rather than weaknesses. Teams can be most effective by putting people in the right role.

The architecture path

This path is for those interested in designing systems. Architects remove the burden of unknowns from teams through research and experimentation, allowing teams to focus on implementation and testing. Instead of guiding people on how to interact with others, they can demonstrate patterns and best practices; they help grow the team’s logical, not interpersonal skills.

While these roles are still technical, interpersonal skills can still help architects thrive. A separate people manager can enable them to work well with others.

The continuation path

A developer may not be interested in managing people or designing a system. These people may settle for roles they don’t want because it’s the only way to get a raise. Having a promotion level I through V can retain talent while still providing additional responsibility. These people are the ones keeping junior developers in line with the team standards during code reviews. They also discuss and implement solutions collaboratively with architecture.