Making the Move From Techie to Manager

It's not uncommon for standout techies to move up the ranks to IT management. Management assumes that techies are fully prepared to lead the group because they excelled in their previous position and know the ins and outs of the group and projects that they're being asked to manage.

Unfortunately, in most cases, this assumption is only partially true. The techie's deep understanding of the project's history, challenges, design and implementation prepares him to give the team a level of technical guidance that a manager from outside the team could not -- at least, not without a steep learning curve. Also, a techie-turned-manager will be familiar with each team member's workstyle, strengths, weaknesses and hot buttons and can use this inside information to effectively manage the group. Even with all these advantages, there are some tricks to keep in mind as you apply your understanding of the group and its projects to achieving successful project management.

First, recognise that no matter how closely you've worked with these teammates, you can't afford to act like their buddy. A common mistake of techies-turned-managers is that they try to position themselves as buffers between top management and IT techies. Each time they request something of their former teammates, they apologise and try to justify it by explaining that it's what the top management wants. The manager typically does this because he feels awkward or bossy giving orders to former peers. However, if a manager doesn't assume proper control of the team and project, the project typically veers off track and the team members lose respect for the manager. Essentially, this is a path to failed projects, low morale and team-member turnover. Although it may seem awkward at first, the best way for you to help your former teammates on a professional level is to take charge and do whatever you believe is needed to lead the team to success. Because you know them well, you are uniquely prepared to craft a management strategy that suits the group's unique personality, effectively leveraging the team members' strengths and compensating for their weaknesses.

Next, consider what you and your teammates liked and disliked about previous managers. Determine how your ideal manager would lead the group and treat the team members. Then, start the personal development (reading, training and so on) required for you to become that ideal manager.

In my opinion, one of the most important things for an IT manager to do is to mentor the team members. A deep understanding of the team's projects and the members themselves is invaluable for this task. However, remember that the best path to long-term team success is to avoid tackling the challenging tasks and problems on your own and focus your energies on teaching the team to handle them effectively. For instance, offer high-level strategies for solving the large problems, and then let the team members propose ideas for the lower-granularity details. Before design or implementation, ask team members how they would design or implement the required technology and why, then discuss the pros and cons with them. Also, discuss the possible problems that could arise with different paths and offer strategies for avoiding them. When it's time for a design or implementation review, ask the team members to discuss why they made the choices that they did. Provide them with the freedom and creative opportunities that they need to grow professionally, yet don't hesitate to help guide them in solving any problems that seem to be holding them back from success.

Here are some additional tips for leading a group to success:

  • Avoid micromanaging or nitpicking. If the team requires micromanagement, it's a sign that more mentoring is needed to help them grow professionally.
  • Understand details, but always maintain a high level of understanding of the project's goals. If you lose sight of the forest for the trees, you won't be able to effectively prioritize tasks and ensure that the team satisfies the most critical requirements.
  • Check that team members are following best practices. Establish requirements for metrics, code testability and test-case creation, and then verify that these requirements are actually being satisfied.
  • Ask for data to support what the team members are telling you. For example, don't believe that code works unless its functionality can be verified. Don't believe that the team is on track to meet a deadline unless you have objective data that shows it is progressing as expected.
  • Understand that writing software sometimes leads to dead ends and mistakes and that team members occasionally need to rethink and rewrite code. As software evolves, give team members the freedom to rewrite code when they think it makes sense from a design perspective.
  • Constantly consider what training, technologies and so on would help the team members do their jobs more effectively. Think back to what would have helped you when you were on the team, and be open to suggestions from team members.

Adam Kolawa is co-founder and CEO of Parasoft, a vendor of automated error-prevention software and services in Monrovia, Co-author of Bulletproofing Web Applications (Hungry Minds, 2001), Kolawa has contributed to and written more than 200 commentary pieces and technical articles for numerous publications. He holds a Ph.D. in theoretical physics from the California Institute of Technology.

Join the newsletter!

Error: Please check your email address.

More about ACTCreativeHungry MindsINSParasoft

Show Comments

Market Place