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:


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:

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

EditText of this page (last edited December 25, 2004) or FindPage with title or text search