There will come a point in your career where you may be asked to manage technical teams who work outside of your technical area. Effectively, you will be a nontechnical manager of a technical team.

This situation poses a whole new range of challenges. You won’t be able to rely on your technical expertise to get you out of a pickle. While your technical experience gives you insight into some aspects of your team’s work, there are other aspects that will be a mystery to you.

Know What You Don’t Know

Technical people are used to being the smartest person in the room. Now you are managing a room of people who know a lot more than you do.

Don’t try to fake it. You know how easy it is to spot a poser in your own technical specialty. What makes you think it is harder for someone in a different specialty?

When you speak to your team, you can still pull out your old war stories to demonstrate the importance of the values you are trying to instill in the team. (The time the change went bad to demonstrate the importance of testing, for example.) Technical people are similar enough in mindset that we all appreciate each other’s stories.

But when it comes time to discuss approaches to a problem or the guts of a technical issue, your job shifts. You are no longer the senior guy who can propose solutions. Now you are the facilitator to make sure that all the technical experts in the room have a chance to be heard and have their ideas considered.

I had a bit of fun at the expense of nontechnical managers in the Introduction and Chapter 1. When a technical person takes over leadership of a team in a different specialty, that person is effectively a nontechnical manager. Not only that, the new manager has some distinct disadvantages over his or her nontechnical colleagues:

• Habits of a professional lifetime. Suddenly, your reflex to just fix what is broken is problematic. Your job is no longer to propose or implement solutions. Your job is to facilitate conversation and to get your team the resources to resolve the problem.
• Lack of training. A lot of nontechnical managers have training or degrees specifically about how to manage effectively. Most technical people have focused their attention on technical training, not people management training.
• Public reputation and persona. Your nontechnical counterparts are used to dealing with you as the person who knows the answers and can provide solutions at the drop of a hat. If you try to keep this up in a specialty where you don’t have the answers, you will just get yourself into trouble.

These are all barriers, but you also bring some significant advantages to the table:

• Experience managing technical people. Usually, by the time you manage people in another specialty, you will have been supervising people in your own specialty. A lot of the same skills will translate.
• Street credibility. As long as you don’t claim to be an expert where you are not, your expertise in another specialty will be viewed with respect by your team. They know that you have paid your dues with late night troubleshooting calls, and that you understand the rhythms and organizational challenges they have to deal with.
• Credibility with management. Since they know you have been in the trenches, management will expect you to be able to translate between the technical and nontechnical people in the organization. This may be the most important role of a technical manager at any level.
• Maturity. You may not be older than the people you are managing, but you may have a more mature view of how IT works than a lot of your subordinates. (Not all of them, of course. You will rely on the seasoned experts in your team to help you steer clear of pitfalls.)

Listening

Throughout your management career, you have needed to develop skills in listening to your team members. As you have matured, you have recognized that you can’t carry the entire load on your own and have come to rely more and more on your team members.

Now listening is the skill that will make or break your success in managing your new team. If you try to carry your team based on your own expertise and experience, you will fail. You need the input of your technical people more than ever before.

The advice about integrity and patience in Chapters 1 and 6 now has to be read in a different light. You will need your credibility more than ever. You will only earn it by listening to your team, identifying the roadblocks, and helping shift those obstacles out of the way.

You are not going to learn anything while your mouth is running. Shut your mouth and open your ears.

Demand Clarity

Communication demands two participants. Your job will be to listen. Your staff member’s job will be to present the information in a way that you can understand it.

If you don’t understand, ask clarifying questions. This doesn’t mean that you need to understand every detail of every change request. But you do need to understand some things:

• What is the business impact?
• What are the risks (in business terms)?
• Are we mitigating the risks?
• Have the service owners signed off on the risks?
• Have we done thorough preparation?
• Are the right people involved?
• What obstacles stand in the way?
• What does your staff need from you?

Teach your team members the skill of communicating technical information to a nontechnical audience. It is sometimes painful for technical people to shift gears and “dumb down” a presentation, but it is a necessary professional skill. Your team members need to understand that developing communication skills will help them to be more effective. Nontechnical people are more likely to give your staff the resources they need if the requirements and consequences of the request are communicated clearly.

Process

There are times when your team will be eager to move ahead with a solution before testing is complete. Since this is not your specialty, you will need to ask probing questions before giving the green light to changes.

This is a balancing act. Your team may view this as “interference” in an area where you don’t know what you are talking about. Be careful about this dynamic, but you need to start as you mean to continue. Emphasize the importance of planning and testing. If you need to trot out some of your war stories to explain why the process is important, do that. But politely and respectfully insist that the process is followed.

You are no longer in the position of being able to accurately characterize the risks of a change. Over time, you will get a feel for who on the team is a cowboy, and whose judgment you can trust on risk estimates. In the beginning, insist on the process. The process is not just your friend. It is theirs too, even if they don’t recognize that yet.

Teamwork

Your team’s ability to work together smoothly will be a major predictor of your success. Do what you can to foster a team spirit. This may mean bringing in bagels and beverages from time to time, or it may involve some team playtime.

When you are developing a team spirit, make sure that you keep the focus on the work the team will be executing. It is nice to have a great group of people who like to paintball together on the weekend, but your job and theirs depends on your ability to deliver as a team.

But the ability for people to relax and let their hair down in a trusting environment can sometimes bring deep issues out for discussion. Project meetings can sometimes be so fraught and tense that people don’t want to be the messenger who speaks to a serious underlying problem. When people are able to relax and trust, they are more willing to discuss issues in a nonjudgmental, casual atmosphere. And a relaxed atmosphere can also help foster the sort of nonlinear thinking that can point the way to a resolution for an intractable problem.

Blame and Responsibility

Because you really don’t quite know what you are talking about, you can be subject to manipulation by team members who are trying to shift the blame for a problem onto someone else.

The best way to avoid falling into this trap is to foster an environment where blame is unimportant. Make sure people are responsible for particular requirements, and that they have agreed to objective criteria for validating those requirements.

But hear out any reservations the person has on accepting responsibility for a particular area. There may be assumptions or interactions that you are not aware of. This is all part of your learning curve as a manager of a new technical area.

Learn

You’re a smart person. You have a demonstrated ability to learn technical subjects.

Ask your team members for resources to learn about what they do for a living. They will respect that you are putting in the extra effort to understand what they do.

Don’t assume that you will be able to become an expert in something that other people have spent years learning how to do.

As you learn, you will be better able to represent your team’s concerns to your own peers and management.

Summary

Managing technical experts in another field is a turning point in your career.It is as big a leap as moving from the trenches to leadership in the first place.

Hold on to the same soft skills that have brought you this far. Don’t pose as an expert in a field where you are not. Listen to your technical experts and help them talk themselves to the right answer.

Discussion Questions

1. What is similar between your technical specialty and that of the group you are managing? What is different?
2. Think back to your most effective nontechnical managers. What did they do with your team that was successful? How much of that can you replicate with your new team?

Further Reading

Berkun, Scott. Making Things Happen. Sebastopol, CA: O’Reilly, 2008.

Stellman, Andrew, and Jennifer Greene. Applied Software Project Management. Sebastopol, CA: O’Reilly, 2006.