It is not uncommon for strong technical folk to find themselves accidentally become a manager. Here is my guidance for those in this position.

There are managers and there are managers. For some team leadership comes naturally, but many are what we might dub the "accidental manager".

This isn't purely an occurrence within the IT sphere. I've spoken with mechanics who told me they were so good on the tools and the factory floor that management saw them as the natural person to take on supervising the workshop. Before long, the mechanic was no longer repairing cars but dealing with overtime costs vs. fixed-price revenue, disciplinary matters, and other administration.

In a similar fashion, there are IT workers who consistently demonstrate value to their employers. They are diligent workers, producing quality and robust outputs in a timely and cost-sensitive fashion.

As a company expands it will recognise it needs greater strength in its IT department, and it will recognise it needs a dedicated leader of that team. It no longer is sufficient for IT to report to the Finance Manager or whoever else it may be, who ultimately does not understand IT but knows costs must be controlled and the finance system must keep running.

So who best to choose but that hard worker who speaks TCP/IP, SQL and LDAP fluently?

Thus a hard-core techie is now running a team of sysadmins, developers, DBAs, analysts, web designers and others. They focus on project timelines and deliverables, with company strategy and direction, with budgets and cost controls.

This is the accidental manager. Unlike the cynical Peter Principle - where everyone is promoted to their level of incompetence - the accidental manager is where they are precisely because they earned the trust and confidence of the executive.

Even so, this trust and confidence doesn't make it any easier for those who were happy cutting code and installing servers to now be delivering negative feedback to their team or to slowly and sadly recognise they are becoming merely an end-user on what was once their own network.

For some it may even be the case they got into technology because it was better than dealing with people, only to find that ultimately all problems are people problems and now they're running people, not infrastructure.

For these people - new and inexperienced technology managers, the naturally introverted who dread giving a bad performance review, the person who was good on the tools but now has to face the budget - here is some advice and some philosophies to assist you in your journey.

The standard you walk past is the standard you accept

Nobody likes to give or receive negative feedback. It's not pleasant. Yet, avoiding doing it will only lead to greater problems. If you are aware one of your team members is delivering substandard work you are then faced with a decision. You can do something, or you can do nothing. Yet, doing nothing is still a conscious decision. You are making the choice to not act.

By not correcting poor work you are implicitly endorsing it. Your staff member may believe their work practices or habits are correct and acceptable and this is reinforced by you, their manager, being aware of how they operate and not saying anything to the contrary.

By not correcting poor work when you become aware of it you lose the right, in my opinion, to raise it at a scheduled annual review meeting or similar such routine review. You cannot go into meetings with surprises; if someone has been doing the wrong thing and you tell them they have been doing so for six months of course the first question they ask will be "Why didn't you tell me before now?"

You may hate conflict, and nobody takes pleasure in delivering bad news. Yet, as ugly as the task is, that's the job. More than that, it's your responsibility. Think about this next point -

Your team's performance reflects on you

You are tasked with the effective operations of your company's IT infrastructure, applications and communications. You have your team reporting into you with their own specific tasks.

However, it is a truism that "the buck stops here." If there is a fault, downtime, a programming issue, something which causes a loss of business continuity you can be certain it is you who will be asked to explain. It is your job, your responsibility, to deliver continuity of systems and to give the business confidence in uptime and stability.

What are you being judged on? Consider that when someone in your team makes an error or does not deliver to your satisfaction or standard. What are you accountable for and is your team helping you in those goals, or are individuals in your team hindering this? The sobering thought of explaining to the Managing Director why you have not delivered results may be the incentive needed to help you correct the practices and habits of those reporting in to you.

Please read on for more ...

Checklists

Here's a tip. Make checklists for routine processes. If you have a team member underperforming and not delivering to your expectations then implement checklists.

Depending on the nature of the work this is not always easy - after all, unlike finance for example, most of IT is projects and abnormalities rather than consistent routine processing. Yet, there are processes - creating a new user account and configuring a new PC for use are two immediately obvious examples. It does not take much thinking to extend this to higher-level activities. What is the release procedure for new builds of your core applications? What is the process for upgrading software and ensuring it is tested, data is secured and all stakeholders are aware?

Make your checklists and ensure they are followed, and if need be, signed, dated and filed. Don't rely on people knowing what to do because you told them verbally, or because they have done it "a hundred times" or because someone else "trained them".

You need certainty, you need predictability and you need reliability in outputs. At the same time your team member needs a clear understanding of what is expected of them and what the correct outputs are. If they miss a step in the checklist it is much easier to bring this to their attention than to chastise them over something they possibly should have known but there is no record they ever did.

At every minute of every day what is the one thing I alone can be doing that adds the greatest value?

The secret of every great manager is adding value in the way that only they can do. There is a lot of talk about delegation; some people delegate everything and you wonder what they actually do themselves. Other people delegate nothing and are overburdened and become a risk to the business if they leave or become unwell, while at the same time they complain they can never get a day off. You need a balance in between. The problem is delegation doesn't come naturally to all people, particularly the accidental manager who simply got where they are because they were the person who got on with the job. Now they are the one who, without any management training, has to ensure are effectively others do the job.

I recall some managers whose view was they did everything they physically could, and delegated the overflow. Yet, this confuses activity with achievement. Sure, you may have the knowledge and ability to do every task your team can, but as manager your time is more valuable. It is inefficient and it is wasteful to have a higher-paid resource performing a lower-skilled task.

Instead, one of the keys to great management is this: think to yourself "at every minute of every day, what is the one thing which I alone can be doing that adds the greatest value?". Do that. This is what your priority is. The rest of the work can be delegated.

If you are uncertain what tasks to delegate to specific team members, consider this -

Staff = a big task list

When you are given a project undoubtedly you know in your head the various tasks that must be performed. You need to add a certain bit of code, you need to modify a database, you need to make a new distribution group, you need to reconfigure a router, you need to do this and that, some items depending on others, some more complex, and some requiring greater time to achieve.

Consider that your organisation chart is essentially a big task list. Your company does what it does, be it to produce a product, deliver a service, something. If your company was a black box that would be its output. How this output is achieved is by a variety of processes, through a series of different departments, and ultimately down to the level of individual people who collectively combine as the machinery that makes this output happen.

So too, your team is your task list, so to speak. You deliver IT services, communications, infrastructure, information and applications. How you personally achieve this is through breaking it up into tasks - which then maps to your staff. For each specific process, how does it flow through your IT department to achievement? Who is the person who has to touch it at each point?

Clarity

To be a great manager your team must have clarity and certainty about their roles and your expectations.

I touched on this above when referring to performance reviews; you cannot go into a review and surprise someone. They should now beforehand if they are doing a bad job (or conversely a good job). It is unreasonable to deliver negative feedback for a problem which has been ongoing for some time and which has never been previously raised.

Do your team members have up-to-date position descriptions? Do they know how you like to be reported to and how much detail you require on projects and problems? Do your team members know the goals and performance metrics they will be assessed on? If the answer to any of these is 'no' then it must be addressed, and the person to address that is you, the IT Manager.

Your team require, expect and deserve clarity. They must know what their responsibilites are and how they will be measured on these.

Communication

Ultimately it comes down to communication. This could have easily been the first point, but I have left it to the end because you will see it is essentially the end result of the points above.

Sometimes the stereotype of an IT worker as an antisocial, shy, nerd can be true. However, it's moot. To be an effective manager and to enjoy longevity in your role you must be a communicator. You need to talk to your team, to ensure you are on top of what's happening and where projects are at. You need to talk to the business to deliver change, to understand requirements, and to keep stakeholders abreast of service problems and deliverables.

You will find most any problem can be accepted and tolerated, and even aided, by your colleagues in the business if you speak with them. People will understand if things go wrong, if deadlines are delayed due to competing priorities, and most anything bad that you will encounter - provided you tell them and talk to them.

We work with data networks and phone systems and push e-mail, but all the technology in the world does not help if we do not communicate.

These are my tips for management success. Management may not come easy to the hard-core techie, but that doesn't mean you cannot unlock the achievement.