To become a tech manager and learn how to be good at it is difficult. There isn't a great deal of 'documentation' available and developers don't discuss the topic a lot. Just take a look at your average code conference, there are very few talks on management. Sadly this means most new tech managers and lead developers learn on the job, which isn't always ideal.

I've been a tech manager for two years now and it's been a real learning curve. There are lots of thoughts and insights I could share, but there are five I believe important. They are useful for any aspiring manager or lead developer, and even those who haven't considered a move into management yet.

Great Developers Make Great Managers?

There is often an assumption the most skilled developers will make the best managers. And a developer should not go for a management role unless they are the best developer in their team. This is a fallacy and a lie, you don't have to be a great developer to be a great manager.

It is important you have experience and a good understanding of code and technical issues, but you don't have to be the best in your team. Management is about a lot more than your field of expertise so don't let your code capability put you off a management role, you may be great at it.

A good analogy for this point is football or 'soccer', which like development is a highly skilled profession. Let's begin with a question, what do the following football managers all have in common?

• Alex Fergusson
• Arsene Wenger
• Pep Guardiola
• Jurgen Klopp
• Jose Mourinho

Answer: none of them were particularly good at football, at least not exceptional. They are though some of the most decorated managers in the game.

The theory goes average football players make better managers because they have higher empathy. They get more out of less capable players because they better understand their limitations and how best to use and deploy them. Great players by contrast often can't comprehend why average players can't do what they can, leading to frustration and arguments.

Average players may also focus on developing other skills such as communication and strategy that are useful for managers. There is a good article on some of the data behind football managers in the FT that covers some of these issues. It's worth a read for any aspiring manager.

Overall football and sport highlight that many of the best managers are not always the most technically skilled. So remember that technical weakness does not exclude you from a management role.

Mistakes Will Happen

This is simple, when you begin your career as a manager you will make mistakes. If it's your first management role you won't know how to respond to every situation correctly. In the two years I've been a manager I've made numerous mistakes; I've hired the wrong people; I've overreacted and become angry unnecessarily; and I've been too ambitious which has led to failures.

The reality is you will make mistakes and it's ok, own up, apologise, note them down, change and move on.

Expect the Unexpected

No one can write a precise guide to management so expect and be prepared for the unexpected. You may have a lot of experience dealing with technical problems but when you become a manager you will have to deal with issues that sit outside your technical expertise.

You will be exposed to people's personal issues; their mental health problems; their love lives; their arguments; a wide range of issues. Expect this and be prepared to deal with these issues in as measured and sensitive manner as possible.

Learn to Compromise

This is important, you are not always going to get your own way and you are going to have to make the best of bad situations. Tech teams sit within businesses, so technical issues and consequences are not always going to drive business decisions. As a manager you are going to have to negotiate and compromise with other departments and managers that have different motives and aims.

Sometimes these aims are going to conflict with technical best practice and may effect your team negatively. You can't always respond in a combative or belligerent manner. You are going to have to compromise and come up with solutions to deal with these issues.

One way to do this is to define what your 'lines in the sand' are and then compromise on everything else. This is a two step process that focuses on what is understandable to the non-technical and what may have a negative impact on your organisation. Usually in financial or reputational terms.

Code principles for example fail to match these criteria as they're not understandable to the non-technical. You can't for instance turn around in a meeting and say, "I simply refuse to release the product this week because Dave's code doesn't comply with the Single Responsibility principle..."

// Dave's Code
// Convert every integer in the array so it is divisible by five.

public function everyValueDivisibleByFive($array)
{
    $newArray = [];

    if (!count($array)) {
        $result = 'error';
    }
    else {
        foreach ($array as $row) {
            if ($row % 5 != 0) {
                $remainder = $row % 5;

                echo $remainder;

                if (5 - $remainder < 3) {
                    $addition = 5 - $remainder;

                    $newArray[] = $row + $addition;
                }
                else {
                    $newArray[] = $row - $remainder;
                }
            }
            else {
                $newArray[] = $row;
            }
        }

        $result = $newArray;
    }

    return $result;
}

Dave's code is terrible but it works. This is all the business cares about and nobody in any other department is going to care about its quality. This is not to say you shouldn't encourage your team to follow code principles. But for various reasons you're not always going to be able to follow them so there is no point being belligerent about them.

A better 'line in sand' will focus on an issue like security. This a more understandable topic for the non-technical and can have a direct impact on an organisation. As an example you may outlaw certain tools such as WebMin or PHPMyAdmin. These tools can help developers and improve efficiency but they also expose servers and databases across the web so can be a security hazard and a business threat.

Other good 'lines in the sand' include:

• Testing: demand that there is time to QA and test before release to reduce the number of bugs found in production.
• Budgets / Timelines: demand that budgets and timelines match what can be delivered so developers face less pressure and produce fewer bugs.
• Deployments: demand that code isn't deployed on a Friday so fewer problems occur over weekends when they're difficult to fix.

All of these issues are understandable and easily explained to the non-technical. They will also stand as solid principles to guide your team and provide them with the time and space to develop bug free and secure software. Overall this will be good for your business, reputation and profit margins.

Keep Coding

There is no reason to stop coding when you become a manager. I rarely code at work now, but I continue to work on personal projects and regularly attend tech conferences. It's important to keep your toe in the water and there is no reason you shouldn't.

Get involved in an open source project, or write and maintain your own library. It only has to be a few hours a week. But if you continue to code it will help you stay in touch with what your team members are doing; what is happening in the wider tech community; and maintain your passion for the subject. This will increase your team's trust in your decisions and help you better advise your organisation. Overall this can only help you as a manager, so keep coding.

The transition from developer to manager can be difficult. But I believe the above tips and advice highlight you can learn to become a better manager in the same way you learn to become a better coder. It just takes time, patience and persistence. I also hope that this post encourages more of you to consider a management role. More managers with technical experience can only be good for our industry, our clients, our work, and our fellow developers.