Problem Solver to Problem Setter — An IT Specialist to Manager Mindset Shift

The below reflects a point-in-time of my personal leadership journey (which is still in early days), as I continue to learn more about this dark art.

The Peter Principle says that people in a hierarchy tend to rise to “a level of respective incompetence” or to put it plainly someone who’s good at their job is often promoted to the point where they’re no longer good at the job anymore due to new demands, scope of responsibility, and day-to-day actions. While humorous, this principle can hold truth, especially in the world of IT. We’ve all heard about, worked with, or (worst of all) had to work for the manager with limited people & strategic leadership skills, who was promoted because they were a superstar technical specialist and management was the next logical (or sometimes only) rung on their career ladder. Transitioning from an IT specialist to leadership position is challenging, both due to well-known reasons (challenging conversations that affect peoples’ livelihoods, clear vision-setting in a cacophony of noise, decisions that you need to make quickly but rarely get the time you want to prepare for), and because the skill that gets many IT specialists promoted sometimes needs to be actively restrained.

That skill is problem solving. It’s the reason why many of us got into making software in the first place, since the flow state that solving a good challenging problem gives us provides a rare form of satisfaction & joy. A specialist’s job is to solve problems, and the better they are at that, the better their outcomes. Many IT specialists are so good at solving problems that they’re fast-tracked into management, with the idea that they’ll become a role model for the other problem solvers that now report to them. This new manager, unless they shift their mindset away from needing to solve every problem in their scope of responsibility, can quickly find themselves burdened with ineffective teams, under-challenged reports, suboptimal solutions, and a todo list the length of a novelette. Why is that?

Specialist Skills Atrophy — But You Pick Up New Ones

This can be a hard pill to swallow for the superstar specialist who moved into management, but pretty soon your direct reports are going to be a lot better at programming, software architecture, and codebase design than you are. It’s a simple matter of where time is allocated. (Hopefully) most of their day is spent writing code and designing systems, while most of your day is spent in meetings, conversations, and visioning sessions. Your specialist skills will atrophy while theirs will (hopefully) grow.

This is ok, because you’re also picking up new skills. The ability to understand peoples’ motivations, matching them with interesting work that allows them to grow along a path they find fulfilling. The ability to hold challenging but productive conversations in a manner that results in mutual understanding & a path forward. The ability to establish & communicate a clear vision towards a larger goal that can then be accomplished with the great people you bring on board. These are skills you build as a manager, that specialists don’t usually have the opportunity to develop.

Personally I see a manifestation of this skills trade-off in the relationship between myself and the senior developers who report to me. While I tend to coach junior developers more directly on the tao of software making, helping them hone their problem solving & decision making skills based on my own experience, I know my senior developers usually know more about the nitty-gritty of making well-designed code work than I do. So instead I put more focus on providing feedback (all of us have blind spots we’re not aware of, and it’s good to get a heads up about them before our compensation’s affected), ensuring they feel satisfied with the work they do & the place they do it, and seeing what I can do to make their software-making lives more enjoyable & productive. It’s ultimately their job to know how to build great software, and my job to set the vision & ensure they have what they need to execute on it.

You Don’t Have the Time

As your scope of responsibilities increases you’re in more meetings, handling more internal & external requests, and responsible for more vision-style work that spans across teams, projects, and even programs. As a result you simply don’t have the 25+ hours per day needed to get your hands dirty with every design & architecture problem. It also becomes challenging to keep up with low-level details across a larger swath of domains, meaning the only way to stay on top of things is to go more “high level”, and trust your people to manage the details.

Instead of Solving Technical Problems, Do This:

Define the problem or vision, get people both within & outside of your team to care about it, ensure the right people are “on the bus” to solve this problem, and get the $%@# out of their way, enabling instead of micromanaging them.

This model allows both you and your team members to utilize each person’s optimal skills. You leverage your leadership & visioning skills to look “above the trees” and provide direction, while they use their problem-solving skills to reach the destination. Both elements are critical, and both suffer when the wrong person’s trying to (or having to) do them.

There Are Still Problems You Need to Solve

Just because you’re a manager doesn’t mean you never get to solve another problem. Instead your problems look different from those of a specialist. Your problems to solve are often:

• What direction should the team go to deliver maximum short & long-term value? How will they know if they’re going in the right direction? How can I help them shift course if things aren’t going well?
• How can I enable experimentation & organizational learning that may yield long-term improvements while still ensuring sufficient progress towards shorter-term goals?
• Who should I bring on board, and how do I align them so each person can do their best work, enjoy what they do, feel like they’re growing in the direction they want, and function well within the collective team?
• How do I ensure people are held accountable for their work, and feel fairly recognized (via compensation and other factors) for good work that they do?
• How do I ensure my team has the resources (budget, contacts, equipment, etc.) to execute on the vision?

These keep most managers more than busy enough, and are problems that only the manager can really solve. So next time you feel the urge to peer review an open pull request, ask yourself if you’re neglecting any of the above problems, and if that’s a better use of your time.