It’s 2017, and that means I’ve been in various engineering management and technical lead roles for about 6 years. That’s long enough to learn something about management, but short enough to remember clearly all the mistakes I made early on.

When you first become a software development manager, it can be a very jarring experience. When now asked about being a manager, I find some key lessons have emerged.

To get a grip, you must loosen your own

This may be the least obvious.

For years I had been an effective technical leader. I ran a tight ship, saw that no bug slipped through the cracks, never left the build in a broken state for long, quickly jumped on flaky tests, and chased down any bug we didn’t understand, no matter how odd.

So when I first became a manager I continued to operate like this, but even more so. I gripped the team even tighter. But you must actually loosen your grip, allowing your team to partially fill your previous role. If you don’t, you risk micromanagement, undermining morale, and not having enough time to do your new job.

Trust at the start, or trust at the end — it’s your choice

To loosen your grip, you must trust your team. And you’re going to do this whether you want to or not.

If you don’t trust your people at the start, you’ll demoralize them, they won’t work as effectively, the team’s work will slip, schedules will be missed, and quality will suffer. What happens then? In the end you’ll be up against a deadline, with a large amount of development ahead of you, impossible to do by yourself. So you’ll have no choice to ask your team to push even harder, and you’ll be so short of time you’ll have no choice but to trust them.

Don’t blindly trust — you need to manage and evaluate, after all. But start by choosing to trust, get to know your team, and see how it goes.

Embrace your role as an information clearing house

Once you become a manager, almost overnight, you’re a clearing house for information. Questions from other groups come your way, your team direct their questions to you, you’re put on mailing lists, you receive requests from sales, you are providing status reports in meetings. It’s often hard to understand how you’ll do any real work.

But this is a core part of being a manager — new managers usually underestimate this part of the job, often by an order of magnitude. The key is to embrace it, and do it well. Over-communicate with your team, tell them what is going on. And realise you’re not a fraud passing on their updates to others in the company — it’s your job now.

Developers are not computers

Obvious, I know, but hear me out.

As developers we deal with computers every day. We pride ourselves on a clinical approach to problems, and dealing with systems that do exactly as instructed. And when dealing with our fellow developers we maintain the same mindset because it works.

But it won’t work when you’re the manager. Even the most focused, talented developer on your team cannot be treated like a computer. Simply giving her precise instructions, asking for the task to be executed, and expecting flawless performance, will not work.

Never lose sight of this fact. The people who work with computers day-in, day-out are as emotional and unique as every other person. You cannot program them. You cannot core dump them. You must work with them.

Yes, your success is in other people’s hands

This is often the most disconcerting fact of management, and one that might seem impossible to handle as a new manager. How can you be successful if you need to rely on other people so directly?

The key insight is that while your success is in their hands, their success is in yours. Everyone wants to be part of a well-run, successful team — a team that executes, holds itself to high standards, provides opportunities to excel, and achieves great things. You, as the manager, have the most control, of any single person on the team, over these factors. Make even a few of these true for your team, and your team will deliver. Just wait and see.

It’s hard to fake that you care

Often, when one wonders about what it takes to be a good manager, you are asked “Do you like helping people? Do you like to help a team succeed?” I used to hesitate at these questions — particularly as an engineer. My response was often “Well, I don’t really think about this stuff. I just want to program, and build well-engineered systems. And I want to learn.” Becoming a manager sounded, well, mushy — and engineering is not about being mushy.

Then I understood. Really understood. Successful software development is not about computers, it’s about people. Once you truly embrace this fact, the real work of development management becomes so much easier. Not easy mind you, but easier.

But it’s hard to pretend. People are smart, and sincerity is hard to fake. But if you really believe that it’s about people, you may be ready to be an effective manager.

The three types of software developers

Let me put it another way.

In my experience there are three types of software developers. There are the ones who don’t realise it’s all about people, are great at their work, and do fine.

Then there are the ones who know it’s so much about people, embrace this fact, and want that to be at the center of what they do — that superb engineering can only take place when the team that will build it, the team that will market, and the team that will support it, are embraced.

And finally there are the developers who realise it’s all about people but who resent this fact. If you understand this, and understand it’s a tragedy, you might just be ready for management.

You’ll get better

Let me finish with this.

If you feel lost or ineffective as a new manager, the good news is that you’ll get better — much better. Just like software development, time is a powerful teacher. Experience will improve your pattern-matching systems enormously, and one good decision will build on another.

When your first project ships, it’ll be like magic, and then you’ll say I am a development manager.