Transitioning From Developer To Management? 541
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?"
Recommend (Score:5, Funny)
A comb for the pointy-hair on the sides of your head and wax for the shinny top.
Re: (Score:2, Funny)
Re:Recommend (Score:5, Insightful)
This can be true in a passive sense, when a good manager acts as a blast shield to protect the team from things such as
Re:Recommend (Score:5, Funny)
A good manager = a good buffer.
If you have buffer overflow there will be a heap of unwanted behavior from your employees.
Re:Recommend (Score:5, Interesting)
I also agree with the "good manager = good buffer" statement, but I'd even take it a step further. Great managers have requirements analysts, support personnel, etc. get the information from the customer. Then they form a plan and assign tasks to their development team. In my experience, this works rather well.
I'm totally going off on a tangent... back to your original question. Karl Wiegers' Software Requirements and More About Software Requirements are both geared towards requirements analysis, but have a lot of info that anybody in IT (and especially project managers) would find pretty useful... Both are worth checking out. I've also heard lots of praise for The Mythical Man-Month, but I've never gotten a chance to read it. Besides those, I would skip books on general management techniques and go straight for anything on software engineering or project management. The R.S. Pressman [rspa.com] website probably has even more recommendations.
Damn (Score:5, Insightful)
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".
Re:Damn (Score:5, Funny)
Great, you broke it to him. Such tact.
Leadership and management (Score:4, Insightful)
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.
Re:Recommend (Score:4, Interesting)
Mythical Man Month is a good read, I highly recommend it. Sure, it is full of things that you'll say "no duh" when you get done reading it, but you'll have read it and you'll know for certain not to make those mistakes. Plus you can whip it out when other managers ask you about software stuff and you'll look impressive because they haven't read it.
I would say this: be lazy. Try to avoid doing anything that makes more work for you and your team than is necessary. That doesn't mean that you should avoid work... it just means that you need to apply yourself and your team in the most efficient way possible.
I would also say this, don't be afraid to be certain of something and never be afraid to be proven wrong. If someone proves you wrong, concede the point and move on. Don't get stuck following a bad decision with justifications. Get back on track and move on.
Good luck too!
Re: (Score:3, Funny)
Too technical of a statement. You are not management material. Add some buzz words that you have not understanding of and you'll be a hit!
Management should be like lubrication in an engine (Score:5, Insightful)
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.
Interesting analogy (Score:3, Insightful)
Re: (Score:3, Insightful)
Re:Recommend (Score:5, Interesting)
All this is sort of avoiding the primary, fundamental issue: when you are a manager you have the power (and responsibility) to fire someone.
This is the real rub. Can you do it?
In my case, I came to a decision that I needed to fire a developer who was completely inadequate to the position. Only this: she was one of the sweetest, kindest people I have ever met. Additionally, if I were to let her go, she would be sent back to India - forcing her husband to also go back. It would have been devastating to them.
So what to do? She was not able to perform her job function and it was costing the company revenue. On the other hand, I wouldn't have been surprised to see Bambi walk up and eat out of her hand whilst blue jays perched on her shoulder (this is how kind hearted and sweet the girl was).
And I had to fire her.
So I tried.
And failed.
I came to find out this about myself: when confronted with a tearful employee who says she'll do anything, including work for half the salary if only I won't fire her - I cave.
This turned out, in the long run, to be one of the worst management decisions I've ever made. I agreed to keep her on at a reduced salary. She continued to perform inadequately but over time she had been with the company long enough that dismissing her wasn't an option.
Everything she wrote ended up having to be completely rewritten and she wasn't learning from experience or coaching. Even though she was working at a reduced salary, she ended up costing the company a high multiple of her salary in lost productivity, alienated clients and rework costs.
So what was the "right" thing to do in that situation? On the one hand, I felt a moral imperative to help this kind, tender and wonderful person. On the other, I had a commitment and moral responsibility to the company I worked for.
Finally, I reached the correct solution: I resigned my position as manager of the team.
As I'm sure you've noticed, I am personally not suited for management. I will never put myself in that situation again.
Just because I'm a talented developer, doesn't mean that I have the ability to make tough managerial decisions when they are called for. Those are two different skill sets, and one of the reasons that I tend to not resent my managers. Firing someone is brutal, and unless you are comfortable with those types of decisions and _sticking_with_them_ I strongly recommend that you avoid the managerial gig and stay in development.
-Clay
Re:Recommend (Score:4, Insightful)
Re:Recommend (Score:4, Insightful)
Re: (Score:3, Insightful)
Right on! One of the things I need to do as a team leader is to identify and reduce the damage from incompetent programmers. Incompetent programmers not only have less productivity, often they have negative productivity, the grand parent post is good example. Letting them work on the code creates more work for the rest of the team.
When firing the incompetents i
Re:Recommend (Score:4, Insightful)
I had to look past the sunbeams and imagine the impact both on the firm and the guy if he stayed on. It wouldn't have been good for us, or for him. The guy should have been a life coach or a priest and by not taking the step of sacking him I was keeping him from a chance to do good somewhere else. Sucked having to tell him.
Then later I found out he'd fabricated everything in his resume in the first instance, coached his friends to act as references (who looks past the phone number?) and screwed up a bid that would have employed another dozen peeps. Sucked finding that out.
Advice? Don't assume you know everything about people, just like you never assumed you knew everything about software or hardware. HR people -- good ones -- can help, and so would a bit of reading about psychology, body language, every possible fad or truth about knowing people from the best sources you can find. People are a lot more difficult than software. Learn your subject, grasshopper.
Re: (Score:3, Interesting)
This guy, "Hacker X," signed on to do a bunch of stuff, and just flat-out didn't do it. He was working from a remote location much of the time, which
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
Indeed, that's why every manager, on the first day, gets a private meeting with Dr. Spaalzbad and his faithful assistant, Gorky, who proceed to remove his brain and replace it with shredded paper from Legal. Thus the new manager can becoming overtly concerned over the mundane, stupid and non-existent, say the most moronic things, and possess no evidence of intelligence.
Re: (Score:3, Insightful)
The only caveat: as a manager you have a lot more freedom to goof off... don't hang yourself with that freedom.
Scott Adams' "serious" books FTW. (Score:5, Informative)
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.
Re:Scott Adams' "serious" books FTW. (Score:5, Insightful)
She's not an idiot. She's just not technical. There is a big difference between the two.
Your advantage is that you've got the technical background
For now. You have a technical background for now. I used to be an engineer, and a pretty good one at that. I was certainly one of the top technical people at the company when it came to understanding and solving customer problems. I've been a manager for two years now...and my technical skills are shot. I know enough to keep up with conversations, but ask me to do any real down and dirty troubleshooting and I'm back to being a babe in the woods.
It's not that I dislike the manager role; it presents some interesting challenges. But don't rely on your technical skills to save you when you're flailing as a manager, because within a month or two your former co-workers and now underlings will be passing you by.
Uh, no, she's an idiot. (Score:3, Insightful)
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.
Re:Scott Adams' "serious" books FTW. (Score:5, Insightful)
Yes but the difference is that an intelligent, non-technical person will know that they are beyond the area of their expertise and stop and ask a technical person about it whereas an idiot will happily charge in without a clue. Hence she is an idiot.
More on topic my advice to a new manager would be the above: do not be afraid to stop and ask questions from your underlings. You might be worried that it makes you look ignorant but it is far, far worse to not ask questions and do something really stupid like the aforementioned judge. Think about it: would "Judge Asks for Technical Advice from Expert" make Slashdot headlines (assuming Zonk is on holiday
Re:Scott Adams' "serious" books FTW. (Score:4, Insightful)
In fact, the judge made a perfectly reasonable order which all three of you have completely misunderstood before happily charging in without a clue.
So, who are the idiots?
Getting back to the original question, this exchange certainly demonstrates why managing developers (and IT people in general) is so difficult. I don't think there's any other field where people have such disproportionately inflated assessments of themselves and so much misplaced contempt for others.
Re:Scott Adams' "serious" books FTW. (Score:4, Funny)
Are you in this field by any chance?
With a 4 digit Slashdot UID? [slashdot.org] What do YOU think?
Judges have an ego issue (Score:3, Interesting)
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 ord
Is there an obligation to understand the ruling? (Score:5, Informative)
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.
Re: (Score:3, Interesting)
No, she is an idiot for judging thing she does not comprehend. if she does not comprehend a case, she has no business going further until she does have a basic understanding of it.
Quite the contrary. It is exactly her business to judge the case -- she's the judge. And furthermore, contrary to all the ranting from high-riding idiots on slashdot, she does understand the technology. In ruling that RAM is a document, all she is saying is that they need to store the information in that 'document' in a more permanent format, for use in the trial.
Re:Scott Adams' "serious" books FTW. (Score:5, Insightful)
Re:Scott Adams' "serious" books FTW. (Score:4, Insightful)
I also ANAL, but I am in a leading role in the technology management of my company and deal with legal inquiries regularly. I would say that Yes, the judge could order you to do this. No different than the fact that companies are required to maintain copies of chat messages, which also are generally transient.
Because it is physically possible to do what is being requested by the judge, either in your example or the ruling in the case, then a judge can order you to do it. Just because it means a little work on behalf of the company is not a valid reason for not doing it. If the company could prove a severe financial burden would be caused by the ruling, then they might (again, IANAL) be able to argue against it. I don't think that is the case here where the judge is basically saying to add persistent logging capabilities.
Re: (Score:2)
Moreover could you define what a "copy of the RAM" is? Is is a single one off or do you need to continually copy the RAM (maybe diff it??) to make it available? The point here is moot anyway, I would assume that the Judge in this case is perfectly well informed, the aim, after all, is to get the IP addresses of those connecting to the service, not the whole contents of the systems RAM. I am sure
Re:Scott Adams' "serious" books FTW. (Score:5, Funny)
Combs not needed (Score:2)
best management book ever...EVER! (Score:5, Insightful)
Re:best management book ever...EVER! (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Re:best management book ever...EVER! (Score:5, Informative)
Much like The Art of War is really about how to make Peace, How to Win Friends and Influence People [wikipedia.org] is not about how to make others just do what you want... it is about understanding the elements of social conduct which make us tick. It's about how to inspire the people you work with. How to hold your tongue, when you truly shouldn't say anything. How to accept the good ideas of your coworkers, and how best to speak when their idea isn't so great.
It's one of the most valuable books on social conduct that you can ever read. Check it out.
- DaftShadow
BEWARE (Score:5, Insightful)
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:3, Interesting)
At least with a cliff, the pain is short-lived and they can replace you quickly.
Re: (Score:2)
Key to that is what does the company expect from you and what is the managerial style of your would-be-boss? If you are going to be in charge of people who's jobs you know how to do well, and your would-be-boss is more team leader than dictator in their approach they you will probably be fine. Just delegate all the work, then facilitate the work being done in your department. The best managers I've ever worked with (I'm freelance, I've worked with alot of different types) hav
Re: (Score:2)
The saying is true, but often misunderstood and misused.
Having gone through a similar transformation about 4 and a bit years ago (and something similar but less extreme about 14 years ago), I can only say that I'd be very scared of an (ex-)techie who, when he turns manager, feels comfortable from the start, or even before he accepts the offer. That person may have been overlooked as a talent and his promotion hence long overdue, but that woudl be a (frustrated) exception. More likely than not such a person
Word Processor (Score:2, Flamebait)
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
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
The best advice won't come from a book. (Score:5, Insightful)
Always listen to them and hear what they're telling you.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
A good mentor would also be important. Start having lunch with an old boss that you really liked.
This is the best advice in the topic. Your job is to optimize the output of the people below you, often by making their jobs easier. (It's no use paying someone lots of money to order pens and paper from Staples, etc...) They will tell you what they need, you just have to listen and empathize (DIFFERENT THAN sympathize, managers often have to make some very un-sympathetic decisions). A great manager is one who balances those needs with the needs of his/her bosses while making both parties happy.
I highly re
Management is realtively simple (Score:5, Insightful)
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.
Re:Management is realtively simple (Score:5, Funny)
Re:Management is realtively simple (Score:5, Funny)
You've clearly got no idea how to be a manager. Let me translate that for you...
Be people-smart with a view to enhancing workplace synergy.
Respect the value of human capital. Gift a space for discussants to talk through their concerns and add value to the dialogue.
Work smarter, and keep on top of your key performance indicators.
Prepare for, and manage, corporate disconnects.
There, now you're ready to be a manager!
Re:Management is realtively simple (Score:5, Funny)
Re:Management is realtively simple (Score:5, Funny)
I'm pleased the concept resonated with you.
Re: (Score:3, Funny)
I see we're on the same wavelength! Shall I calendar lunch?
Running shoes.... (Score:5, Informative)
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.
Re: (Score:3)
. . . exaggerating percentages until engineers laugh at you, . . .
resources? (Score:2)
Your own experience! (Score:5, Insightful)
Training up your replacements?.... (Score:2)
The Dilbert Principle (Score:3, Funny)
> look to for guidance in this transition?
The above captioned book has everything you'll need to know.
Where have you been? (Score:2)
What did your previous managers do? Do what they did except improve on the issues that you thought were lacking.
Depending on your organization, I would generally say that a managers job is to make sure her people are happy and productive. That includes kicking them in the ass when the need it, insulating them from corporate BS and finally, making sure they have the resources they need to get their jobs done.
Saving Private Ryan quote... (Score:4, Insightful)
"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!
Development to Managerial - People skills... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
One, remember - management is more about people skills than technical expertise.
I would say that it's very important to remember that the skills needed to do a job aren't the same as the skills needed to manage people doing that same job. One of the most important things to remember, IMO, is to stay cool-headed. Try not to get rattled. If you're frustrated, annoyed, scared, or confused, then try not to let it show.
As a manager, it's your job to keep your peers and superiors informed about anything tha
Mentoring (Score:5, Informative)
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.
I found situational leadership model useful (Score:2, Informative)
Took a training course in this quite a while back:
http://www.chimaeraconsulting.com/sitleader.htm [chimaeraconsulting.com]
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 t
Good Topic (Score:4, Insightful)
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.
Sun Zi (Score:2)
Sun Zi (or Sun Tzu), seriously, it is a big hype in the management world but it is a great work on strategic thinking, really.
Disclaimer: IANAManager, just someone who studied Classical Chinese at University, and from that point of view I would say get this [google.com] not that [google.com]. Or maybe on of the million Sun Zi for manager/marketing/whatever books, but then you got the hype.
School of Hard Knocks? (Score:2, Informative)
Your spouse and your confidence.
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,
Look into certs (Score:5, Interesting)
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.
Personally (Score:2)
My advice (Score:2)
Don't manage. (Score:2, Insightful)
Remember that, always.
Now ask your self, do you want to be a good manager, or a succesfull one?
If you want to be successfull, don't manage unless you absolutely have to. Allways do as the boss asks you to do and allways have someone else available to blame when it fails. Make sure the someone is not in a rank above you, make sure it's not a friend of the boss or his wife. In short, success depen
People Skills (Score:2)
On the intellectual side ? Move away from "perfect" solutions- beg
It's not complex, but not easy (Score:5, Informative)
Good resources for you:
Some tips:
YMMV, and good luck!
Well, firstly... (Score:2)
Secondly, I would buy a thick book of management jargon. If you cannot say "prioritize" and "going forward" and "methodologies" and stuff like that, how will you ever go forward with the right management priorities and the possibility of blaming someone else?
Thirdly, I would attend a big management course. Now I happen to be selling one right now....
My advice? Go back to the coding now, before they swallow you alive. Alive, I t
Been There (Score:2)
1. Don't completely count out good management books. A few good read-while-you-commute-or-fall-asleep books are: The One Minute Manager, The Essential Drucker and Getting Things Done.
2. Absolutely, as you know, stay on top of good software architecture design patterns and UML. Even if you don't type a single line of code ever again, make sure you can discuss all aspects of an enterprise application using design patterns, SDLC and good practices.
3. Learn Visio (or similar Apple / open sourc
Don't do it (Score:2)
If you're not groomed into the role, you
Peopleware (Score:2, Informative)
Can't recommend it enough really - it helped me plenty.
http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439 [amazon.com]
Communication Breakdown (Score:2)
Therefore, I recommend as starters:
Old proverb (Score:2)
Being a manager is uninteresting to an engineer (Score:2)
Rands in Repose (Score:2, Informative)
Hard choices (Score:2)
What do you need? A referral from Dr. J. Walker, (Score:2)
If you want to manage then you'll have to forget everything you know about the technical side of your former job. You don't have time for it now, and there are people who do that for you.
Get used to meetings. That's your life now. You'll have meetings inside of other meetings. You'll be in two meetings at once in two different rooms. I wouldn't make this up, you know.
Remember those times when you were on call and had to work the occasional weekend? You still do that, only it's all the time now. Any
37 pieces of flair (Score:2)
Advice? (Score:3, Insightful)
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...
Be sure you want to do this (Score:4, Insightful)
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?
good mentor and good habits (Score:3, Insightful)
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.
Rands and Joel (Score:4, Interesting)
Rands on Management: http://www.randsinrepose.com/cat_management.html [randsinrepose.com]
Rands's Book: http://managinghumans.com/ [managinghumans.com] (Direct to Amazon: http://www.amazon.com/Managing-Humans-Humorous-So
Joel on Software: http://www.joelonsoftware.com/ [joelonsoftware.com]
Good luck! It's great to hear about people who care enough to want to do it right.
Different set of Technical Problems (Score:3, Insightful)
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
It was the best of times... (Score:3, Insightful)
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.
The hardest job in the biz... (Score:4, Informative)
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.
But not worse than ACs bitching and moaning (Score:5, Insightful)
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.