Slashdot Mirror
Transitioning From Developer To Management?
An anonymous reader writes "After 15+ years as a code monkey, mostly doing back-end systems design / development, I was surprised by recent developments at my workplace that have resulted in my being transitioned into a dual architect / managerial role within the next few weeks. While I am somewhat confident at this point in my career in my experience and training for an architect-type position, I have serious concerns about being able to properly fulfill the role as manager. Aside from 'Become a manager in 2 days' type books, what resources would you recommend I look to for guidance in this transition?"
>> what resources would you recommend I look to for guidance in this transition
A comb for the pointy-hair on the sides of your head and wax for the shinny top.
Lindsay Blanton
RadioReference.com
"How to Win Friends and Influence People"...it's a cheezy title, but an awesome book!
Ever heard the saying "people are promoted to the level of their own incompetence"? Unless you're comfortable with a management job I would strongly recommend you *NOT* take it. You're right in doing some research and self-education before accepting the job, but while you study up keep asking yourself "do I REALLY want to do this?"
It will come from the people to manage.
Always listen to them and hear what they're telling you.
1. Treat others as you would expect to be treated
2. Never assume that anyone has nothing to add to a conversation
3. Keep your shit together; be organized.
4. Realize that even if you follow the above rules there will be politics and CYA that will make you miserable from time to time.
Seriously though, once you've semi-transitioned into a management position, don't expect to have any time to do any other work during normal hours.
You'll spend 120% of your time in meetings, doing paperwork, reporting on issues to upper management, delivering managements responses to underlings and never have a moment to yourself.
You'll find yourself doing your own tasks after that, so that a normal 40 hour week will become a normal 60 to 80 hour week, and you'll still feel like you're falling behind.
Who is general failure, and why is he reading my hard drive?
Take some time to reflect on the managers you've had experience with. List the good and bad traits they had. Think about the hard decisions they made well and the ones they made poorly. Then see how you think your style of management can benefit from those lessons. (This assumes you have already thought about your style of management, otherwise that is step one.)
> Aside from 'Become a manager in 2 days' type books, what resources would you recommend I
> look to for guidance in this transition?
The above captioned book has everything you'll need to know.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
My favorite bit of wisdom of a superior:
"Gripes go up, not down, always up."
No matter how dumb an idea is from upper management, try to put a positive spin on it to your employees, but if it's truly stupid then gripe like hell about it to your boss!
Read my Very Short "Stories"
As a convert from the front lines of IT (Mainframe operation and network engineering) to management, there are a few things that will help. One, remember - management is more about people skills than technical expertise. This is NOT to say that you will not be amiss to keep your development skills up to snuff. Being able to speak engineer will make you a more suitable manager, as that will be one less barrier for you to cross that other management types will have to scale.
Leaping in does work for some people - but if your company has tuition reimbursement, I would seriously recommend taking management courses in a college environment. While a lot of people seem to think that management is a snap - there is things that seasoned professionals and professors can teach you that will keep you a step ahead of common pitfalls of entry-level managerial work.
If you really MUST do it solo, you could look into obtaining a list of books used in a Business Administration program and seek to study them in your own time. Many have valuable insight into little encountered tid-bits that might not seem valuable at the time - but can crop up at the strangest times and places.
And remember - it's an art as well as a science. A good rounded education will allow you to relate to the more human aspect of management versus the technical part of the development career path you held.
Find managers who have styles that you like and respond well to, that have teams that are regarded as highly effective, and that have good reputations with other management types. Talk to them, learn from them, as them for advice. When I transitioned from desktop support to management, I talked to my father (who worked his way up in the glass industry from apprentice to Executive VP, and knew nothing about computers). Learned a ton, and it's helped me greatly.
Also, don't be afraid of asking your upline for guidance and direction. He/she will know that this is your first foray into management, and if they're any good at all, will expect you to ask questions. It's not a sign of weakness to ask when you don't know something.
Finally, think about the bosses you've had over the course of your career. Do the things you liked them doing, avoid the things you didn't like. This is one of the best ways to find what your own management style is.
Took a training course in this quite a while back:
http://www.chimaeraconsulting.com/sitleader.htm
Also, knowing those ENTJ, INTP etc personality types
and how to work with different personalities and
workstyles (including your own), is useful.
Basic leadership principles like consistency,
taking responsibility, listening to concerns, and
giving people real reasons to be motivated and happy
to come to work.
Learning to let go and trusting that your team really
does amplify your own work output if you let them do
the things they know how to do, and support them.
Be firm and focussed, and demand that, when required,
but lighten up and keep it a fun place to work
cooperatively.
Don't micromanage everyone, and don't set artificial
and ridiculous targets just for the sake of appearing
organized or in control.
Where are we going and why are we in a handbasket?
I'm going through something similar myself. I've found that I've had to readjust my up-front goals. As a coder, I was more interested in how to accomplish something and, in point of fact, getting it accomplished.
As a manager, I've found it becomes just as important to demonstrate progress (not just results), and to make sure that what has been asked of me is achievable, measurable and makes business sense for the company.
Also, don't underestimate the importance of compliance stuff (SOX if you are with a public company, HIPAA if with a medical organization, PCI for credit cards, etc.). It all seems like a big waste of time but getting through audits and such is critical.
And, for those who say "don't take the management job, ignore them." When they have to move out of mom's basement, they will be more sympathetic to you.
One, you will screw up eventually. Two, screw ups build character and experience. And, three, every CEO has bags of regret he carries with him at all times as a reminder, no matter his formal training or degree. In other words, time, patience, and a good shoulder to lean on. My brother is a VP with Rockwell Corporation. He will tell you the same.
Probably not the answer you were looking for, but, take this virtual pat on your shoulder, and "go get 'em tiger!"
I hope, when they die, cartoon characters have to answer for their sins.
Project+ and CAPM are geared towards your need, with the PMP focused more towards very well-seasoned project managers.
I just recently became a lead and know from the projects I've worked on, that I would be a better manager. So I'm finally doing something about it and pursuing the project management path. I just picked up the All-in-One CAPM/PMP exam guide and the recommended study path for the CAPM is a month. As with most jobs you'll learn the bulk from doing it, but the cert won't hurt and may give you the jump start and mind set to help you get started.
some folks love certs and some hate them, but I've never had issue with getting them and I've always learned a few things along the way no matter how well I thought I knew a particular topic.
Creationists are a lot like zombies. Slow, but powerful and numerous. And they all want to eat our brains.
Do whatever the little white dog tells you to do.
Actually, I would Scott Adams' "serious" books: The Dilbert Principle and Way of the Weasel are pretty good explanations of why managers act the way they do. Your typical PHB usually has very good business reasons for the stupid things he does, but since he's technically incompetent, he'll attempt to achieve these valid business goals by means that are unlikely at best, and impossible at worst.
Witness our earlier Slashdot thread about a judge not knowing that "storing" logs in RAM is fundamentally different than "storing" logs on disk. She's got a good legal reason to expect that when someone is told to "turn over the logs", that they turn over all the logs. But because she's an idiot, she's very angry and confused when she finds out that RAM just. doesn't. work. like. that.
Your advantage is that you've got the technical background; the Adams books will explain good (techie) management skills in language that you can use with fellow PHBs. Tell your fellow managers "I make sure my employees can leave by 5pm", and they'll wonder why you're harboring a bunch of slackers. But if you phrase it as "if my employees can't get their work done by 5, then the fault is with our management/scheduling/business processes, so let's, as managers, figure out how to improve those processes", and all of a sudden the PHBs love it.
PHBs are funny that way. As soon as it sounds like it's their idea, they love it. Your job, as a non-pointy-haired boss, is to make sure that the ideas your fellow PHBs "love" will be good ones.
Good resources for you:
Some tips:
YMMV, and good luck!
Dude, no one gives a shit about you life.
Nobody gives a shit about your comment.
Don't speak for the rest of us, particularly when you don't have the minimal courage required to associate your whining comment with a Slashdot handle. Counterpunchers like you a dime a dozen. Talk when you have something useful to contribute. Otherwise, shut your yap. You may learn something.
Read the EFF's Fair Use FAQ
Can't recommend it enough really - it helped me plenty.
http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439
Good advice all around in the posts above. A site I've found to be pretty insightful is Rands in Repose. He's also a new book titled "Managing Humans". Check it out—I'm a fan.
-- Ryan Price http://www.ryansdesigns.com
You seem to be implying that he should try it first.
My response is "why?"
Have you ever tried a career as a hair stylist? Why not? You never know, you might be really good at it.
You probably haven't tried it because you're not trained for it, you never studied for it, and most of all, you weren't interested in it. (My apologies if you really are a hair stylist, but given this forum's nature, I think it's a pretty safe assumption you aren't, so it should be a good example.)
It's the same with this guy's new position. What makes these morons above him think he has any skill at management, or even any interest? This seems to be a fundamental flaw in managerial thinking: that everyone else wants to be a manager too.
I have a technical job because that's what I studied for, and what I was interested in. If I wanted to be a manager, I would have majored in "Management Science" instead. That's the degree for people who want to manage. If companies want managers, these are the people they should be hiring. They don't move software developers into marketing roles; they hire marketing people for that. They don't move software developers into human resources roles; they hire HR people for that. They don't move software developers into finance roles; they hire finance people for that. So why don't they hire managerial people for management roles?
Context matters.
Someone who isn't technical would be your grandmother, to whom RAM doesn't matter; nor does her idea of how RAM works really matter to anyone. (Other than to simply annoy you when talking about computers with yer grandma.)
A Federal Judge who has no interest in stopping by even their local mom and pop computer shop to learn about something she so obviously knows nothing about, when the livelihood of people is at stake, is an idiot.
1) Your people come first.
2) Support your people, come hell or high water.
3) See #1.
4) Keep any distractions that aren't absolutely necessary away from your folks.
5) Don't sign up for any critical technical work (you'll just slip the project).
6) Oh, in case I forgot to mention, fight like crazy for your people.
7) If your people are working overtime/weekends for more than a well-bounded, short term crunch, it's a sign of a problem, not a good sign at all. Kick your folks out and figure out what's going wrong, and fix it.
8) Don't constantly look over everyone's shoulder.
I'm no fan of Microsoft, but there's a book published by Microsoft Press by Steve Maguire or Steve McConnell (whichever one of them didn't write Code Complete) about technical management. It's actually very good indeed.
The combination of manager and architect sounds like a very dangerous one to me. It's going to be very difficult for you to get honest technical feedback from people who report to you, and architects need that kind of candid feedback. An architectural error that goes unchallenged for political reasons is bad news. When I was a manager, I once led a software integration team (a more suitable role for a manager), and even that caused some tension. Not with the person who happened to report to me -- she had no trouble pushing back when needed -- but with another engineer who found it uncomfortable when I had to go around and get commitments from people. I was actually selected for that role because initially no one on the team reported to me (I was the one leadership/management role who didn't have an interest in a particular component within the project), but things change...
Check out the Project Management Institute (PMI) and start working towards getting your Project Management Professional (PMP) designation. It will be worth salary dollars, too, and will help you move elsewhere when you have to. Also, read Drucker (anything written by or his stuff collected, like the "Daily Drucker" or "Essential Drucker").
The One Minute Manager book is a good starting place, too, since it will help you with some very basic concepts of how to deal with the social system of managing employees. This is a book that you can read in about an hour, and will at least give you something to start with.
Also, be very candid with your HR department or supervisor and say, "I don't know if I have all the right training for this - what programs are provided for training?" If you live near a major university or other big industry companies, there may be off-site programs (like UCLA's great technical management program, next one is in mid September), that are specifically for you. Think about it this way: what if they just said, "you've done such a great job programming C, we think you have enough experience and maturity to program in X, and teach it too." Your first response would be, "what's this X language, and when are the training classes that you are providing?" Far too many people fail as managers when they get promoted because they were never offered nor sought out the proper training.
links:
http://www.pmi.org/
http://www.uclaextension.edu/tmp
Search amazon for Drucker and One Mintute Manager
It's si-LAY-us, you Silly Ass!
If there is one essential that I'd recommend it is formal training in project management.
I finished an MBA at a reputable university a few years ago, and the thing that really stuck was project management. Of the various project management approaches I'd particularly recommend PMBOK (project management body of knowledge.)
This really is "MBA in a box." You will get a good smattering of budgeting, communications, human resources, timing,quality etc, and a way to hold all this stuff together.
Good luck!
I've been "stuck" at the architect level for 10 years now. Several years ago, I was considering going into management, to eventually become a VP of engineering. But I really enjoyed the hands-on work, and really loathed the management work -- schedules, resources, reviews, hiring, .... I thought about this for many months. I finally talked to my boss about it. He made a very good point that decided the issue for me once and for all. He pointed out that if I didn't really enjoy being a manager, I would be awful at it, and that would make me miserable.
I realized I have something I'm good at and really enjoy doing. In the interest of not spoiling a good thing, I decided to stay a techie and I've been very happy with my choice.
Are you really sure you want to make this transition?
first off, i don't envy you --- i found myself in a somewhat similar situation recently where i suddenly became responsible for squeezing useful results out of three different subcontractors.
as for resources, first, and most important: it's been mentioned elsewhere, but finding a good mentor (preferably more than one) is going to be crucial. think of them as "man pages" for people.
second: i don't know what your personal organizational style is, but you're about to start juggling not just your own personal assignments, but all tasks of your entire team, plus all the "overhead" tasks of tracking progress, planning, etc. if you're not used to juggling about 5000 balls at once, get yourself the tools you need to help keep yourself organized. in my case, this meant a giant whiteboard with a matrix of tasks cross referenced to people and due-dates which i updated once a week after a brief status meeting.
third: start looking at your local community college's certificate / continuing education programs in business development / leadership development. in addition to more "standard" management classes, i would strongly encourage you to take a class on interpersonal communication, because you're going to discover quickly (if you haven't already) that people communicate very differently with management than they do with their peers. similarly, more junior employees have different communication styles and attitudes about communication than more senior / seasoned employees do.
You never posted on /. until you did. You never drove a car until you tried. You never worked as a programmer until you got hired. Those, and millions more, are examples which make your question unnecessary.
A comparison to a hair stylist is useless because there is no transfer of skill from a programming job, for example. However an artist could do very well in hair styling, it pays well at the top.
Basically, a good coder knows more than he can implement with his own pair of hands. Then the coder gets promoted to a designer, team lead, a manager - where he is given an extension of his hands to do the job that he holds in his head and implements with help of younger, less experienced engineers. Any other use of his time would be a waste.
What makes these morons above him think he has any skill at management, or even any interest?
I would not be so quick to label people I don't know as "morons". It might be unfair, on occasion :-) Besides, if he was chosen out of hundreds of possible candidates then probably there is a reason to try him in this role? Managers are usually good at understanding people.
So why don't they hire managerial people for management roles?
Because most people, and even some managers, understands that Dilbert's PHB is not always optimal ;-)
As an engineer / architect who has had to deal with some frustrating management (most of it indirect, fortunately), I've found these two blogs to be both enlightening and useful for feeding to managers. Rands especially, as a developer who moved into management with a purpose, has some very insightful commentary. He's also recently published a book, which I'm planning on giving to some of my favorite managers (who despite their sincere desire to treat us well, sometimes have a hard time understanding the geeks they herd.)
f tware-Engineering/dp/159059844X)
Rands on Management: http://www.randsinrepose.com/cat_management.html
Rands's Book: http://managinghumans.com/ (Direct to Amazon: http://www.amazon.com/Managing-Humans-Humorous-So
Joel on Software: http://www.joelonsoftware.com/
Good luck! It's great to hear about people who care enough to want to do it right.
I don't think people are giving the judge enough credit. The ruling doesn't say that every single thing that was put in RAM needs to be produced or recorded. The ruling was over a request that FUTURE connections be logged. The company tried to argue that they shouldn't be compelled to log connections because the connection information was only normally in RAM and not written to disk. The judge called that bullshit, and the judge was right - just because you don't write something to disk doesn't mean it's unreasonable to write it to disk.
Now, if the judge ordered the production of items that HAD BEEN in RAM, or ordered that EVERYTHING in RAM was logged, then you'd be right to complain, but that isn't what the judge said. A small set of data was asked for, and 'it's only in RAM' was correctly not accepted as an excuse to not be able to follow the order.
paintball
The best managers reasise that employees don't work "for them", but instead they work for the employees, helping get rid of obstacles so that the employees can give of their best.
Engineering is the art of compromise.
The point is that the oil only enables the engine to function well. It does not act as a fuel and it is not used to directly transport the power coming out of the engine. It simply makes the engine efficient enough that it doesn't overheat and melt itself.
Judges have huge ego issues. ... pretty much literally in their courtrooms. They can't have you killed but they can have you locked up ... indefinably. They can ruin the lawyer's livelihood. They can ruin you financially. They can restrict where to go and what to do.
... too bad, the contempt order is not appealable, you have to sit in jail until the appeals court overturns the underlying ruling on Issue X.
They can't stand to be told that they are wrong. When they are told that they cite you for contempt.
You have to understand that the courtroom is the last vestige of unfettered "aristocratic" power in America. They are Kings
And contempt orders really are not appealable.
The judge, even if they are wrong, can fuck you over any way they want with a contempt order. The classic (and it has been a long time since I read it) case on contempt orders was Martin Luther King. Judge ruled wrongly on Issue X. Cited King for contempt, as part of that. The appealed running was
You really can't go back and sue the judge for damages under that either. They have judicial immunity. The most you can do is try to get them not elected next time and if they are Federal judges they have life tenure.
You get used to that power. You get used to everyone acting in an sycophantic manner towards you. You get used to a world, where people are not allowed to say "No" to you. Then you become unable to handle criticism, however justified however politely worded.
And of course, if the judge wants to act improperly or say something nasty, they just ask the court reporter to stop recording. You, on the other hand, don't have that luxury.
Also, remember when you have an issue with a judge who do you take it up with? Another judge. No conflict of interest there.
So, yeah. The judge is an idiot. Because they have the power to be an idiot and get away with it.
I had this really stupid class in college called "Organizational Behavior". To this day, I still don't know what I was supposed to learn in that class. Despite the class being boring and pointless, the professor was actually a very interesting guy. He said something one time that always stuck with me: "Leadership is the reduction of uncertainty."
Damn. I took a similar class. The main things I remember is that "competent employees are promoted until they become uncompetent" and "It is more advantageous to have a technical person doing technical work and an incompetent person doing mangerial work instead of vice-versa".
I don't think changing management every 3 months makes for a healthy company.
As a coder, your job is to take technical requirements and turn them into code that meets those requirements. Those analytical skills will directly translate into management, but a bit of rethinking is required. Instead of needing to make the compiler produce the results you are looking for, you need to make the people produce them.
As far as retraining, see what Universities near you offer evening or weekend executive MBA programs. Unlike the Day programs that are geared for teaching management consultant grunts to be better management consultant grunts, the executive ones offer a lot of things for mid-level people that are actually in management. In an exec MBA program, you should cover Leadership, Financial Accounting, Managerial Accounting, plus basics in other areas like marketing and finance. An MBA, particularly in an executive format that has fewer elective options, tends to focus on "general management," it's like a liberal arts degree, it isn't specialized, but it designed to give you an overview. You won't become the company's expert on accounting or marketing, but you'll understand the jargon and big picture, so you won't be blown away when doing budgets, etc.
Subscribe to the Wall Street Journal, print or online, and try to read it a few days/week. This was what a friend with a technical background that got a job at McKinsey said she did to catch up on business jargon fast. A few weeks/months, and you'll find yourself less lost in business jargon, because you'll be reading things in the current jargon in context.
Some basic tips:
1. Your primary responsibility is to keep "the suits" from interfering with your team. If you have filled your team with good people, they'll get the job done, but if you let the top people meddle in your team, you will fail.
2. Understand boundaries with your staff... you have to balance a line between being "one of the guys" and being the "boss". Err too much on the former and you won't have the respect necessary to make the decisions, they won't appreciate that sometimes you have to make decisions that aren't up for debate... Err too much on the latter, and you won't get the honest feedback that you need to make decisions.
3. Use meetings regularly, usefully, and short. Long meetings annoy people, but you need some meeting time to keep everyone on the same page. Do NOT become the information funnel to avoid meetings. You need to know everything, but not be responsible for relaying messages. It's not the 1950s where everyone's secretary types memos to send up the chain or down the chain.
4. Build cross-functional teams wherever possible. Setting up a monthly meeting with your technical lead, someone from marketing, and someone from customer service to go over features, for example. If you meet with other leaders and get your technical people together, decision making will be stronger and you'll do better things for the company. Those that show leadership are more likely to move up the ladder.
5. Know where your time goes and why it is work. It is sometimes frustrating, because as a "code monkey," when you pulled an 80 hour week, you know what you did. You have some functions/classes/bug-fixes implemented. As a manager, your primary responsibility is keeping track of what is going on and communicating. This seems trivial to technical people, but is a lot of hard work and get be frustrating. If you spend a solid week in meetings with your team, superiors, and colleagues in other departments, it often feels like you did nothing, but that's your job.
6. Informal meetings are a great way to keep abreast of things, but don't disrupt people. Learn to have task lists. One of the worst senior managers I worked with had a tendency to call people whenever he had a question. I was trying to manage a small team AND do some technical work, and he'd blow my concentration constantly with calls e
While funny, your comment doesn't do much to encourage the OP to move upward into management.
Effective/successful management is a combination of leadership and management. Management is the process of getting things done, repeatability, auditability, process, etc. Leadership is defining direction, pushing initiatives, etc. A typical boss only does management - you see that all the time. But great bosses are a combination of the two. Note that just being a leader is not a complete picture for a good boss, as nothing really gets done.
Yes, it is important for the successful manager/leader to not do the technical work. When a manager/leader starts to do that, he or she becomes too focused on the "what are we doing" and isn't able to focus on the "what should we be doing". Yes, as a line manager you need to retain technical skills, but you shouldn't do so by doing programming or sysadmin. I try to encourage people at that level to not get their hands on systems - you hired competent staff to do it. A big part of making the transition into management is learning to let go of some of your current technical duties. I'd advise the OP, when he makes the move into management/leadership, to stop coding. Do your best to avoid giving too-technical requirements - "we'll use an AJAX app to do ___" is less good than "we need to do ___". Let the tech team decide what technology to use. Your job should not involve technical details.
Dickens' comes to mind here. You're at the door of a tremendous opportunity, but there's an equally unpleasant chance for failure. Number one, you've recognized that you're not feeling ready for the management role. To me, this is a great indicator that I think you'll surprise even yourself in the months ahead. The fact that you're worried about it shows you're not an ego-centric moron who thinks he's God's gift to project development. That said, I'll offer a few bits of advice for you to consider.
If the position is already settled, then go to HR and get connected with one of their senior specialists who works in training, development, or mentoring. Let him/her know that you're willing to step up to the plate, but that you are looking for some additional insight and help as you make the transition. Make it clear that you're looking for support, not some remedial "How to manage in 30 days or less" type material. S/he may be able to hook you up with another, more experienced manager in your firm who can help you during your first few months.
My second point really depends on WHO you will be managing. Will this be your current peer group, or a completely new set of faces? If your current peer group, I'd want to know what your relationships are like right now. Do they respect you? Do they come to you for help? If so, you'll probably fare better than some. If your peers don't think kindly of you, a malestrom could be ahead of you. If a completely fresh set of faces, only time will tell. Remember that your empoyees are going to want to feel you out as much as you are going to need to feel them out. My advice? Sit down with your new team on day one (or before). Give them your background and let them know what strengths you bring to the table (in some ways, this is like a final, non-binding interview). I would tell them that this is your first foray into management, and that you expect you'll make some mistakes along the way, but that you trust them to be open with you so that you may improve. Then (if feasible), announce that you'll meet with each individual briefly to get to know them better (this can be out of the "norm" for most men, but believe me that it goes a long way to establishing a good relationship). Keep those meetings short and light. Talk about the employee's interests and strengths. Many employees long for management changes with the hope that a fresh set of ears may be willing to listen to their dreams and aspirations. Try to learn the employee's preferred communications and learning styles (either by asking, or through observation). Ask them what was best about their last manager, or what they believe makes a good manager. Take note of what they say (mentally, or on paper)! You may not be prepared to provide the type of management they want, but having that list of expectations will give you a good starting point for your mentor discussions, or your time with your HR rep.
Okay. Enough from me. Best of luck to you in your new position. I would love to see an update from you in a year, to tell us what worked and what didn't.
I use irony whenever I can, but my shirts are still wrinkled...
Joel Spolsky is in the same boat as you (as am I, for that matter). He was great technically, so they made him a manager. http://www.joelonsoftware.com/ has some wonderful tips about managing technical folks.
But really, the best advice I have is: Quite and find a job where you can still write code. Management is dreadful, especially if you are one of those people who likes to do things themselves.
I've been a development manager for five years now after holding architect, software development, and software consulting positions for a decade. Here is a list of things that new development managers will learn the hard way -- regardless of how perceptive or proactive someone thinks they are:
1) Your first priority is doing what is right for the company. If you are just trying to always "be the great guy" to your team, you are a horrible manager and horrible for the company. Do the right thing for the company and the rest will follow.
2) You are not an architect anymore. - Let the architects and software developers design and write the software. Your job is to ensure that the team has what they need to do their job.
3) You are not a coder anymore. - Put practices in place which allow the software developers and architects to keep code quality high.
4) You are not an individual contributor anymore. - Your own achievements are solely based on the achievements of your team. You did your job well if you team did a good job.
4) You have to give negative feedback. - People need to know when they are screwing up. If somebody has body odor, you need to tell them to clean it up. If somebody is consistently late, you have to tell them to get their asses in on time. If somebody is a negativist, you have to tell them to get a better attitude. If someone is surfing too much, you have to tell them to stop. If some coder is going off in the weeds chasing butterflies and losing track of a feature, you need to tell that person to get back on task. The worst kind of conflict is ignored feedback.
5) You have to give positive feedback. - When somebody does a good job, tell them. If someone kicked ass on a feature, tell them. If someone finds a hairy defect and fixes it, give praise. If someone works long hours one day, give them a free day off, or give them a gift certificate to take the family out. Whatever.
6) The "open door" policy is lazy bullshit. You have to have frequent informal one-on-one meetings. - People need to venue to vent, ask questions, voice concerns, et cetera. All people. Even the quiet ones. Be proactive and give your team a predictable place to do that. You will offset a lot of potential risks this way.
That's all I can think of off the top of my head. I was a shitty manager at first. Over the years, I have learned each one of the above lessons -- usually after a serious screwup.
Good luck to you new software development managers. I truly believe it is the hardest job in software engineering. But stick with it. Once you get good at it... it can be very fulfilling.