If you’re the CEO of a hip, young startup, you naturally want to be the cool, approachable boss — not the one who distances himself from his employees with ten levels of hierarchy by adding a bunch of extra bosses who are just there to tell other people what to do. It’s tempting to dismiss management as a useless task and try to keep your organigram flat forever.

In tech companies in particular, there’s a common misconception that management is “easier” than engineering.

It’s not hard to see where this idea comes from. Typically engineers will spend years getting an advanced degree — or creating an amazing independent project — in order to qualify for a software engineering job. And then someone on the team gets promoted to head the team, usually without any management training of any kind.

But treating management as easier (or as not really a task at all) can lead to some costly errors. I was once on a team where the least-performing engineer got tapped to manage the team. Apparently the idea was that if he’s struggling with coding, maybe he can at least organize the meetings and put the status updates into the project planning software. And that might have worked out if those were the hardest tasks of the job.

Even worse (and more common) is to tap the most productive engineer to be the team lead. The reasoning seems to go like this: “He’s so good at this — he should be telling all of the other engineers what to do,” and/or “With such a brilliant engineering mind, management tasks should be trivial for him!”

The latter is worse because a team of engineers can kind of work around a manager who is merely incompetent. They just resign themselves to not getting any coding done on Tuesday afternoon because the manager likes to keep busy by have four-hour-long team meetings. But if you have to report to a brilliant engineer who really likes to micromanage your code and showcase his own brilliance, it can make your life miserable in a way that is quite inescapable.

I assume I don’t have to explain this to most readers, but ideally a team lead shouldn’t be someone the team has to find a way to work around — it should be someone who has the skills to coordinate the success of the project. Good tech management is about having an accurate idea of what your team can do, knowing who can do what, knowing who wants to do what, removing obstacles, making sure that your team has the necessary resources, and — when there’s a problem you can’t fix in time — proactively warning stakeholders about it.

It’s a task that grows in complexity and time consumption so quickly that the CEO generally needs to start delegating team management tasks to others as soon as the startup is big enough to divide into teams.

So how to do it?

For the IT department it’s quite simple. An engineer should be promoted to team lead for demonstrating management skills in addition to demonstrating engineering skills. Not for any other reason. In particular, you should never promote someone to a management position as a reward for being good at something other than management.

When you reward one employee with management responsibilities that he’s not capable of performing competently, then you are simultaneously punishing every employee who has to report to that person, and you’re telling them that you don’t value them or their careers.

This problem is an especially sticky one when it comes to growing a tech startup — because the role of the tech lead or CTO changes dramatically in the early stages of growing a startup.

At stage 1, you often need to hire someone who can take an idea that’s described on slides and implement it at superhuman speed so that you’ll have a deliverable product right away. But you don’t have any money, so you entice this engineer with the job title “Chief Technology Officer.” Unfortunately, “the-one-who-personally-writes-all-of-the-code” stops being any part of the CTO’s job description by stage 3, at the latest. CTO becomes a role that involves both architectural and business decisions as well as managing projects and people.

If you are damn lucky, maybe the first engineer you bring on board is someone who’s qualified to perform all of these tasks. That can happen. But if you don’t have the luck or luxury of finding such a person at stage 1 of your startup, then I’d recommend offering the title of “architect” or “co-founder” for your speed-coder if you don’t want to see a messy power struggle arise as your fledgling company grows and the role changes.

You’ve probably heard the old adage that a good engineer is lazy. The idea is that a good engineer is someone who — when presented with work to do — immediately starts thinking of ways to use tools and technology to make the job easier. But a manager is lazy in a slightly different way:

When a good engineer has a good idea, they often think, “I must start implementing this immediately!” Then they go off into a room (or into a trance) and a week later you have a beautiful new tech product. By contrast, the good engineer who would also make a good tech manager thinks, “I want to tell all my colleagues about this idea!” and “I’ll bet colleague X would be good at implementing this part and colleague Y would be good at implementing that part…”

In other words, the good tech manager, when struck with a good idea, starts lazily thinking, “How can I get someone else to implement this?”

It seems counterintuitive. If you have one engineer who churns out reams and reams of code really fast, it’s easy to look at the team and say, “That engineer who wrote so wrote so much code so fast — that’s who should be in charge!”Unfortunately, that’s often the wrong choice because that’s not the most important skill in a team lead.

Picking the right people is actually not that tricky if you remember that management is itself a task. Don’t make the mistake of treating management skills as an afterthought when picking someone for a management position.