So You Want to Be a Manager
by Steven Cerri
Sooner or later, nearly every technical professional is faced with the question of moving into management. The questions that often arise revolve around one major question…“Should I or shouldn’t I?”
That one major question however, breaks down into a whole series of other questions, some that move you away from management and some that move you toward management. For example, some of the questions that tend to move you away from management by putting doubt in the career move are:
▪ “Should I move into technical management or stay technical?”
▪ “What steps are necessary to be a technical manager, and how long will it take?”
▪ “How should I make the transition and who should I get help from?”
▪ “If I become a technical manager, can I ever get back to the technical work?”
▪ “What happens to me if I don’t like technical management?”
▪ “Can I be a technical manager and do technical work at the same time or is this a one-way ticket?”
▪ “As a technical manager will I loose my technical edge?”
These questions often don’t have clear answers. The answers depend on many factors, including the company, the organization, you, your temperament, your aspirations, luck, and a wide variety of factors that are not in your control.
In the midst of all these questions and the resulting uncertainty, there are other forces at play in the decision-making process that may well move you toward management. For example, some technical professionals are often personally motivated to consider a management career because of increased income; or increased responsibility; or an additional sense of power; or maybe it’s just the next step on their expected career ladder. Or the reasons may come from a desire to manage people or the enjoyment of the challenge of bringing diverse resources, including people, together to make something happen. Whatever the questions, there is bound to be a tug in several directions at once as you move from your technical world into the management world.
Upper management however, often has a different motivation for “selecting” a certain technical professional for transition to management. The reasons can include:
▪ “We need someone right now for a small, short task”
▪ “There is no one else I can put on this project”
▪ “Sue has been doing a great job on her technical work. Surely she can manage a team of people doing similar work.”
Notice that none of the above approaches have anything to do with selecting a person based on proven management expertise. Based on my experience consulting, training and coaching in a wide variety of organizations, I can tell you that the “selection” processes listed above may well have the lowest probability of success available. However, seldom is the first management position you’ll be assigned one that you are truly prepared for.
In most cases, an upper-level manager will look at their team and ask: “Who on my team does his or her technical work the best. Ah, it’s Susan or John… they do their technical work better than anyone else.” “Therefore”, the reasoning goes, “if they can do their technical work so well they can obviously manage a program or manage the team or manage the task.” While this reasoning sounds good on its face, it is often not true.
The manager is often in a dilemma. The manager could provide adequate training for the management candidate. However, what happens in most cases, is that the manager will promote to management the technical person who does their technical job the best. Can you imagine a manager announcing that she is promoting to management a technical professional who does mediocre work while passing over the best engineer on the team? It isn’t going to happen.
On the other hand, the best engineer on the team is precisely that because he or she is geared to thinking and moving through the world as an engineer, not as a manager. To make a successful transition from engineer to manager will require that you be prepared to embark on a new career, the career of manager. And it is a far cry from the career of engineer. When I train and coach technical professionals who want to become managers, I emphasize and make sure that they understand they are embarking on a completely new career when they aim at management.
Why is management a new career?
As an engineer, scientist, or technical staff, your education and career were devoted to the pursuit of the “right” answer. Indeed, in nearly any technical or scientific problem there is a “right” answer.
F=ma is an equation representing the Newtonian universe and the answer does not depend on your blood sugar level or your mood for the day. A given force applied to a given mass produces only one value for the acceleration that mass will experience. Whether in the area of electronics, statics, dynamics, chemistry, fluid dynamics, physics, or mathematics, there are “right” answers. Your tests in college were not taken in essay form in a test blue book. As a technical professional there is a “right” answer.
This is not the case for human interactions and therefore it is not the case for management. There is seldom a “right” answer when it comes to most management decisions. There are answers that work, answers that are “effective”… not necessarily the “one-and-only” right answer.
Being effective versus being right
Being an effective manager is not about having the “one-and-only” correct answer in a given management situation. It’s about motivating people and building teams in ways that work, in ways that achieve the operational objective. There often isn’t even one “best” way to manage in a given situation. A given situation may have several paths to the desired operational outcome.
And the most effective way to manage will depend on several important factors. The factors include; the people involved; the project risk; the time involved; and the relative expertise of the team versus the manager.
Here is an example. Imagine you are the manager of a software product development team. Your team has been moving the product development along. It’s now Friday, and Monday is the scheduled first product shipment date. Your team discovers a bug in the software that is a deal-breaker. There is only one person who really understands this portion of the software well enough to fix it quickly but the whole team will need to work together to get the fix implemented and the software out the door by Monday. Now, you know as the manager, that the team has been working hard for the last six months and everyone was looking forward to some time off this weekend. There is frustration, disappointment, and some anger at the situation.
The world certainly would not come to an end if the ship date was missed… but that’s not what your company is about. You make and keep your commitments to your customers, your employees, and to your stakeholders. Therefore, you really want to make the delivery date; it is a message about who your company is and what it stands for.
You have announced your schedule to the world, your boss is expecting it, and you are on contract with your customer for the delivery date.
What do you do? Do you order everyone to stay and fix the software? Do you ask everyone to stay and fix the software? Do you ask the team for ideas? What is the “best” way to handle this situation? How do you positively motivate the team? What’s the best approach?
A new manager would be looking for the right answer. In reality, what they would probably come up with would be an answer that got the product out the door on time and that made the team angry, frustrated, and alienated.
While there isn’t one “right” answer, there are several ways to approach the team and the situation to get the product out the door on time.
Let’s look at two scenarios and the choices a manager might have and what might influence the selection of the best choice. Remember, since there isn’t a right answer, we’re looking for the best choice from several possible workable choices.
In the following two scenarios I’ll outline their conditions and possible motivational strategies:
Let’s suppose I have a very aggressive team of people, most with Type A personalities, who are of equivalent respective competency. Let’s further imagine that I have already established a strong team relationship; we’ve worked together for some time.
Under these circumstances I have at least two management choices. I could simply direct the team to get the job done over the weekend. Under the conditions I’ve outlined above, they would probably comply and feel OK with it.
Or I could pose the problem to them and they, more than likely, would volunteer to work the problem over the weekend.
Therefore, in this scenario, with this situation and with this team I can either be very directive or I can just ask them to solve it and they’ll work out what needs to be done.
Suppose in this scenario I have a relatively new team but with little cohesion. We’ve not worked together very long and their competency is not consistent across the team.
Under these circumstances, I could simply direct the team to work over the weekend. But I would have to monitor them carefully and closely as they worked through the weekend and my direct approach might generate some ill feelings.
Or I could ask for input from the team and see if they voluntarily “step up to the task” by working the weekend.
While I want them to work the weekend, I want them to feel that they are signing up as a team. If they don’t come to that conclusion on their own, then I could step in and direct them. In either case, they’ll work the weekend, but I want to be careful to establish early on that they all have a voice. Once we have all agreed to work the weekend, I’ll indicate that I’ll monitor them closely through the weekend because this is such an important task.
In either of these two scenarios, the important point is that I have several management styles that will get the software out the door on time. There is no “right” answer. There are several answers that will be more or less effective depending upon the circumstances and the teams’ responses to my choices.
As a technical professional making the transition to manager, you must be ready to adopt a new paradigm, a new way of looking at the world…one that allows for ambiguity, uncertainty, and a lack of the “right” answer.