Developer Turned Manager

Often, through no fault of their own, developers are required to become managers. They may be assigned as the TechnicalLead/ChiefArchitect of a project, or may be given a promotion as an indication of the company's respect for their abilities.

The skills and talents that make one a good developer have little to do with those that make one a good manager, and developers generally have little managerial training. Other managers, even the good ones, usually offer little in the way of useful advice. This leads to a lot of trial-and-error learning; it's a SinkOrSwim experience.

Here is some advice for developers who find themselves in this position:

DontPanic -- You can't control everything, but you can control how you respond to it.
Accept your position and take charge -- Most developers are accustomed to trying to achieve consensus with others, and are uncomfortable telling other people what to do or making decisions based upon incomplete information. But now, you'll need to accept the fact that it is your job to make decisions on behalf of the whole team and to ensure that those decisions are carried out. You don't need to be tyrannical about it, and you should certainly listen to others and empower them to do the right things, but remember that you have authority and responsibility. Don't be shy about "giving orders"; that's your job now. Being decisive is often more important than being "right".
Learn to say "No" -- Everyone is going to suggest lots of cool ideas or additional features for your project. As a developer, you may have prided yourself on accepting every challenge. But as a manager, you will have to say No a lot more often than you say Yes. Setting priorities and deciding what not to do are a manager's most important decisions. Don't be afraid to say No to higher-level managers or customers. The people demanding that you do additional work now are the same ones who will rake you over the coals later for overrunning the budget or delivering late. If you overload your subordinates with too much work, the results will be bad.
Manage risks -- Do your best to expose and to minimize uncertainty. Keep a list of TopTenRisks.
Learn to delegate -- You have subordinates: use them! Don't assign important development work to yourself - you will be more busy than you expect performing your managerial duties, and you need to be AccessibleAndInterruptible. It may be frustrating to watch others struggle doing something you could do or want to do yourself, but you have to let other people do the work. Give people clear instructions and duties, and provide positive and negative feedback when appropriate. Don't be too easy on people, or too forgiving of shoddy work - it is up to you to set standards for the team to meet.
Manage upward and sideways -- Managing your subordinates will actually be a small part of your job. A more important activity is interacting with higher-level managers, other teams' managers, accountants, marketeers, and customers. You need to control expectations about the project, and do whatever is necessary to get needed resources, favors, or concessions.
Fight your team's battles -- It is up to you to procure the necessary resources for your team. Do whatever it takes to get those resources. Also, prevent others from interfering with your team's activities. This will require a lot of arguing with superiors and other people in the company, but don't back down. It may be necessary to issue ultimata like "This is what I think we have to do to succeed. If you don't trust my judgment, then I should resign", but try less-drastic approaches first.
Ask lots of questions -- of everyone: your subordinates, your managers, your customers, your suppliers, etc. What you need to know won't be found in books or on the Internet; you need to be tuned in to your specific project and work environment. Delve for the details and make sure you understand what is going on, especially in areas that are outside your realm of expertise.
Learn about business -- If you are like most developers, you've probably spent your career staying away from business courses and keeping yourself isolated from company strategies and politics. This has to change - you will now need some basic understanding of financial accounting, marketing, contract law, and similar fields. Books such as ThePortableMba are useful for learning all the terminology and principles that higher-level managers will be discussing with you.
Learn about company politics -- You may have successfully avoided this in the past, but now you will need to know who you can go to for additional resources and other help. You also need to know who might be working against you. Learn how to collect and trade favors. Go to lunch with the arrogant frat-boys with nice hair who control everything. This is how things really get done. The system may be totally dysfunctional and ridiculous, but if you know how to work it, it can help you.
Be easy on yourself -- You are going to make a lot of mistakes at first. Just accept them, learn what you can from them, and move on. You'll feel overwhelmed most of the time, and you may feel completely incompetent in your new role. It can be a very unnerving experience for someone who is a talented developer; the blow to one's ego can be devastating. Just treat the whole thing as a learning experience, and try to have some fun.
Do a little development, run errands -- Just don't assign yourself development tasks in the project plan. One of your jobs is to maximize the productivity of the team as a whole, and "filling in" with little tasks, doing the boring bits, testing, documentation, and so on is often a good way of doing that. This also helps you keep in touch with the technical side of things.
Overcome shyness -- Many developers are naturally introverted. Managers don't have that luxury. Managers need to be comfortable with all forms of communication, and need to be assertive. Managers have to hold meetings, make presentations, give directions to subordinates, call higher-level managers, customers, and suppliers, and so on. Don't hide behind e-mail: you need to get in people's faces once in a while. It's part of the job, so force yourself to do it, even if you hate it.
Don't accept a doomed project -- If you are being assigned to manage an effort that you believe is going to fail, you need to decline. Resign if necessary. Managing an impossible task will harm your reputation, your professional relationships, and your emotional well-being.

A good start is to realize that Managers are not likely to be good Developers and Developers are not likely to be be good Managers. For the most part our brains are wired differently. The problem is that HR departments think that people are plug compatible and that "weaknesses" can be "fixed" by training courses and a certain amount of browbeating. It is time to accept that human beings are irritatingly, annoyingly unique and you *cannot* force a human being into a particular slot. Instead you have to get the right person in the first place and allow them to do what they are good at. Yes, its difficult, but those companies that crack it *will* be the most successful. The book NowDiscoverYourStrengths discusses this approach in more detail. -- NeilWilson

I disagree with the "wired differently" idea. Development talent and managerial talent are not necessarily mutually exclusive. It is certainly true that being good at one doesn't have much to do with being good at the other, but the only way to find out is to try. -- KrisJohnson

By all means try, but you should not be forced into doing something you are no good at simply because you that is the only way to get a higher salary or a car parking place. Promotion to level of incompetence is an epidemic disease in business. -- NeilWilson

So is the idea that a management position is somehow 'superior'. In almost all my professional work, the manager has been one of the least talented and capable people in the group. The best group dynamics occurred when he or she kept this as an operating principle. Granted, this is probably not describing your average IT workplace, but it works for us.

When you say the manager is the "least talented and capable", are you referring to technical skills, or management skills? I am convinced that being a good manager is a lot more difficult than being a good developer, and that someone with managerial talent is more valuable than someone with development talent. Incompetent management may be rampant, but I think that's due to the difficulty of the job, and not due to inherent stupidity of people who become managers. -- KrisJohnson

Well, I did say this may not describe the average. I mean this; in my current group, I consider our manager to be quite competent. He has a good MBA, and works well with technical staff. However, each member of this group has far more education, seems significantly brighter (of course this is subjective), and performs a significantly more complicated and difficult job (ok, this is somewhat subjective as well, since it is an apples and oranges comparison...) than he does. As I said, this is probably quite different from the average IT workplace, but it works for us (a small advanced R&D group).

Here are some of the ways in which management is different from development:

Focus upon the future, rather than upon current activities.
Paying attention to what everyone is doing, rather than what you are doing.
Breadth of knowledge is far more important than depth of knowledge in any one subject.
Constant interruptions and gear-shifting are part of the job, not just an unwanted distraction. Managers generally can't lock their doors and unplug their phones.
"People skills" are much more important.
Interaction with lots of people with lots of different jobs and opposing viewpoints, rather than interaction with other developers.
Acceptance of responsibility for others' mistakes and shortcomings.
Need to make others succeed, even when the others don't care themselves.
Often have to find the least objectional solution (based on other people's evaluations) rather than the "best" solution (based on personal evaluation).

Don't be shy about "giving orders"; that's your job now. Being decisive is often more important than being "right".

The problem is management becomes mostly about giving orders. Actually having to discuss solutions takes too long and is messy. Managers know best.

Occasionally, but hardly consistently in this business. The trick is not to be too badly wrong.

The other trick is to let techies make the technical decisions whenever possible. Whenever a manager is forced to make a technical decision, it is because the techies have failed in some way. Unfortunately, a DeveloperTurnedManager often doesn't know when to act like a manager and defer to the other techies' opinions.

True. Of course, there is a big difference between a manager left out to dry by their team, and a manager pretending competence they don't have. I agree that DeveloperTurnedManager needs to remember that he isn't a developer.

In my experience, managers eventually talk only amongst managers so they end up deciding technical issues as well.

Maybe I'm lucky, but I haven't had that experience. The managers I've worked with have usually left technical decisions to techies, and generally screwed up only the marketing and resource-acquisition-and-allocation decisions.

I don't understand why the Software Industry can't be the same as other engineering industries. For example, on a Building project, the Project Manager usually is an engineer himself, graduating through the ranks, having years and years of experience. This is perhaps what is wrong in "our" industry, in that the people with the "power" just have not come up the ranks. Probably the major reason why there is a lot of negative feedback about Project Managers in general. -- KarlZdero?

I think the answer to this lies on both sides. Business schools have long taught that someone possessing general management skills can go in and be a successful manager in any industry. This is great if a manager only needs to create GANTT charts, but a disaster if the manager also needs to be a leader for those under him. On the other side are developers who wish to be isolated from everything they consider non-technical. There are very few purely "technical" decisions, and, from personal experience, report that writing and obtaining the necessary justifications and approvals, licenses, training, and support can be extremely time consuming. The "just do it" approach favored by many developers is equally problematic. When budgeting time rolls around and many projects are competing for a fixed pool of funding, it can be fatal if your project has made high level enemies by doing things without their approvals, and these people often have long memories. It is also dangerous for a project if it is viewed as requiring special additional funding because it chooses to do things outside of the company norm. "If 10 other projects can live with this tool, why do we have to buy a different one for your project?" For many reasons, I strongly believe the development managers should be internally promoted from the ranks of developers, but to accomplish this, developers must also learn and understand the non-technical, "management" side of the job as well. -- WayneMack

See ManagementRoles, SoftwareManagementManifesto, ManagerialCoverFire, ReluctantLeadership, RealStoryAboutDeveloperTurnedManager, IsBeingaManagerRewardingAtAll

Contributors: KrisJohnson, WayneMack, NeilWilson, KarlZdero?

CategoryManagement, CategoryEmployment