No spam, no B.S.
Unsubscribe if you’re not happy.
Have you ever wondered why it is that brilliant and talented coders often crash and burn when they get promoted into a leadership position?
Obviously, it isn’t a lack of skills or knowledge. Software developers are often highly intelligent, have undergone strenuous educations, and might have even started a company or two—clearly, they’re both smart and motivated.
So, what gives?
If those who can’t do, teach; then maybe the reverse is true.
Maybe those who can do shouldn’t teach–or manage, as it were.
Is it sometimes helpful if a software manager can crank out code? Sure.
Should a manager have at least a working knowledge or the technology? Absolutely.
But these are not central to the role of managing developers.
The core role of the manager is not to know and understand technology; it is to work with people.
Let’s explore more of what a software development team manager does day in and day out to get a better understanding of why even the best engineers make lousy development leads.
While it will vary on different teams of different types of sizes, in most cases, a manager is there to set priorities, communicate progress, and facilitate day-to-day work in whatever way they can. That’s pretty much it.
The truth is that managers don’t really produce all that much. The job of a manager is to put the right people in the right place with the right information so that hopefully they do the thing you want to happen. Note that this doesn’t mean cajoling people into taking actions or watching over their shoulder to “manage” (aka micromanage) the work they’re doing. That’s just bad management, period.
Management is like one of those wind-up toys that walks on its own when you let go of the key. As a manager, you “wind up” your team with info, point them in the right direction, and hope they go where you’re aiming.
The same is even more true when it comes to managing developers.
When is the last time you complained about your manager because of their technical skills? Chances are you don’t remember because it doesn’t happen often. Or, if it does, it’s probably something like, “He’s asking me to do something impossible because he doesn’t understand how this code works!”
Even in cases where it seems that the divide is a technical one, it’s actually not.
In this case, the real problem is that the manager is demanding a specific action rather than partnering with his team to resolve the issue. That makes them a bad manager, but not because of a lack of technical expertise.
This truth is really what gets to the heart of why technical managers don’t necessarily need to be technical experts–and why technical experts are probably not the best choice for manager.
The true skills that it takes to be a manager are not all that technical in nature.
It’s not about being the best coder in the room or having the most experience with the project. That won’t make you a strong leader.
Being a good manager is all about setting other people up for success.
In order to do that, you need to first and foremost be able to know and understand the people you are managing—whether they’re software developers, cat groomers, Feng Shui consultants, or all of the above.
You need to be able to read them, understand their work styles, and tailor your leadership to fit their needs. You also need to be able to be able to do things like coach people on their performance, give effective feedback, and set priorities.
These skills, which are inherent in good leaders, are not part of the job description for a software developer.
When you truly boil down the role of a software development team manager into its discrete parts, you realize that there is really only one part to speak of.
It’s managing the process–the environment in which the rest of the team must operate.
We often think of managing as being about managing people, but it’s really not.
You can’t actually manage a person, per se. You can’t really force another person to do something they don’t want to do.
Just like you can’t manage another person’s time, the closest you can get to managing another person is to exert forces on them that you hope will lead them in the direction you want them to go. And, generally, if a manager is having to exercise force, it’s because of a failure in culture or communication.
Unfortunately, your commitment to being a great developer will not necessarily make you a great manager.
In fact, it’s likely the opposite. If you enjoy the type of work that comes with writing the actual code and solving the problems, you may not enjoy a managerial role in which you’re not actively doing the same kind of tasks. You may feel drawn to do the work yourself instead of effectively managing the team and helping them perform their best.
While jumping in to help write code may make you feel like you’re being a team player, the role of a manager is as a coach—first and foremost. Doing the work of the team means that the work of the manager is not being done and the members of the team are missing out on opportunities to learn by solving difficult problems.
For example, you don’t see the Warrior’s coach Steve Kerr hopping on the court every time his team is struggling, right? Likewise, not every great athlete goes on to be a great coach, which we’ll explore next.
Many developers have worked their way up the ladder and grown their abilities and responsibilities—only to find themselves ultimately in a management role where they’re no longer capable or satisfied with the work they’re doing.
This is known as the Peter Principle and, yeah, it sucks.
The basic premise is that people are often promoted to a level of incompetence. The underlying assumption is that if someone is good at their current role, then advancing them to the next level is an obvious choice.
In reality, we know that this is demonstrably untrue.
And in development versus development leadership, we know these are different roles that require vastly different skills and knowledge.
Unfortunately, many companies conflate these two things and act based on that flawed logic. They assume that someone who is good as a developer will be equally good as a leader or manager of other developers.
That’s not to say that developers are never capable of being managers, but there is a fundamental disconnect in the logic of assuming that effective coders will be effective at managing other coders with no training or desire to fulfill the role. It’s just not the truth.
Here’s where we dig into the science of this thing.
What is it about developers that leads to them struggling in leadership roles?
To find out, let’s look at what Google has found as they have studied this question quite extensively and they have documented their findings in a pretty clear and easy to understand way.
In their research, Google found 10 characteristics of an effective manager.
Most of them are probably what you would expect–vision, communication, decision-making skills, and other obvious parts of the management role.
Conspicuously absent from this list are pretty much all of the traits you might associate with a great software developer. It doesn’t mention critical thinking. It doesn’t call out problem solving. It doesn’t say a manager should be proficient in the most popular programming languages. In all of Google’s research, it seems they didn’t find that an effective manager needs to be particularly good at development skills—because that’s their team’s job, not theirs.
While you certainly should have enough technical knowledge to understand and effectively advise your software development team on the work they’re doing, Google hasn’t found that even their own managers need to have specific technical skills or experience.
Be ready to answer questions. Provide direction. Lead your team and don’t sweat the rest.
Sure, it’s kind of unfortunate, but it’s a fact of life—developers often don’t do well when tossed into software development team leadership.
Why? Because the skill sets are totally different and because, probably, they don’t really want to do it in the first place!
This problem stems, ultimately, from leadership’s flawed understanding of these roles and a mismatch in the hiring and promotion process. If they instead exercise some of Google’s management behavior like forming clear strategies and discussing career goals and performance with their team, they’ll be able to find both developers and managers who excel in their (very different) roles.
No spam, no B.S.
Unsubscribe if you’re not happy.