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?"
Do not ask; only tell!
In my opinion, your most important resource is your word processing program (hopefully OpenOffice). Using that, you can polish up your resume and find a better job doing what you're trained for and have experience in, instead of allowing yourself to be promoted until you fail.
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.
If you aren't comfortable in your abilty to manage people you shouldn't do it. You will be doing yourself and those who work under you a great disservice. Good developer != good manager.
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?
a red stapler, a flashlight, and some bug spray.
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.)
Well, it's obvious what managers do... just listen to the Code Monkey song by Jonathan Coulton - http://www.youtube.com/watch?v=j4TnhemCEmc
You are using English. Please learn the difference between loose and lose; they're, there, and their; your and you're.
Your employers may just be interested in getting you to train up your replacements. Now would seem to be the time to set up your own company and become a consultant/contractor. In this situation I'd be wanting to write a book to raise my profile.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
The United States Marine Corps Seriously though, I've just been through the same thing, and if you are not willing to tell your coworkers\friends no, you are going to have a hard time. the most difficult part I have had is trying to balance between old friends and new job.
> 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.
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.
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.
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 not that. Or maybe on of the million Sun Zi for manager/marketing/whatever books, but then you got the hype.
"Hannibal's plans never work right. They just work." Amy/A-Team
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.
What traits did you really enjoy and admire in previous (or current) managers of yours?
What traits did you really hate and were you frustrated by in previous (or current) managers of yours?
Emulate the former and avoid the latter. Most of the best managers I've had have managed with as much common sense as the company in question would allow, because you're right: a book, even a good one, on how to manage projects and people can only take you so far.
Having only managed people for a couple years now, my advice would be:
1. Listen to your employees
2. Shut up and listen to your employees more
3. Don't be afraid of confrontation, but do be willing to accept that sometimes the 'right' answer isn't necessarily the 'best' answer.
The best managers I've worked with are the ones that remembered all of the things that had frustrated them as an employee in the past, and took those lessons to heart, and acted on them.
Other than that, management is something that takes trial and error. Some people can pull it off, some never do. Books probably won't help that much; you sort of have to already understand the challenges and resources of a manager before you can really 'get' most of the management books that are out there.
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.
I'd look at what I know, so look at your current boss, look at his characteristics, if he is being promoted fast, copy what he does, if you boss is useless try learning from his mistakes. Your own experience will always teach you more than some book.
Getting to Yes
First, Break all the rules
anything by Peter Drucker
There are, in my experience, two fundamental 'directions' the title "manager" can go in -- one requires "people skills", the other requires the ability to track data. What advice you would need would depend strongly on which of these two directions you're going in. If it's the latter, there's a strong possibility you won't be that uncomfortable in the transition. In any case -- don't be afraid to play the "ignorance" card; rely on other members of staff -- both below and lateral to your position. Honest workers have more respect for someone who is willing to admit what he doesn't know rather than trying to bluster through.
i would recommend the "Tao of Leadership". Excellent resource for well, everything.
Primal Leadership: Learning to Lead with Emotional Intelligence
E motional-Intelligence/dp/1591391849/ref=pd_bbs_sr_ 1/105-3091731-1517231?ie=UTF8&s=books&qid=11883417 74&sr=8-1
http://www.amazon.com/Primal-Leadership-Learning-
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.
Ask yourself "Do I enjoy coding and will I hate my job when I don't get to code any more?"
The only developer turned managers that I know who were successful AND enjoyed their jobs didn't really like to code in the first place.
The ones that did like coding either weren't successful because they spent more time getting their fingers back in the code ( and generally driving their coders nuts ) or they were successful at managing but hated their jobs because they didn't get to code any more.
Peopleware is a great book for this kind of stuff.
Don't Ask Slashdot. All you'll get are a bunch of tired old rehashed snarky crap responses, half of them from people probably too young to even be working anyway. Ask a manager you respect. If you don't know any that you respect, you probably won't like the job anyway.
Done with slashdot, done with nerds, getting a life.
As a good basic starting point go to www.PMI.org. This is Project Management Institute and it provides good basic material and training. If you become a member then you will be able to obtain some good training PMP certification program.
Good luck, most designers I know that move into management drops back to pure development because they hate all the people problems and management pressure because your project is late.
I code a lot less than I used to, and have a few programmers working for me now. Developers are problem solvers, not necessarily coders and coders alone. I find myself still having to solve similarly difficult problems in running a business, managing finances, resources etc and draw heavily on problem solving skills I picked up as a programmer. Why did you start programming in the first place? Because it was easy? There's more to life than computers. If you're up for the challenge there are different types of problems out there outside your comfort zone!
Communicate: up, down, and laterally. If your boss ever turns to you in a meeting and says "I hadn't heard that.", you screwed up. There's NO SUCH THING as a good surprise to your boss.
Don't worry about whether your staff like you or not. It's not part of your job description, and if you worry about it, you'll be paralyzed with indecision. Besides, if you do your job well, they at least won't DISLIKE you.
"The first myth of management is that it exists. The second myth of management is that success equals skill."
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 depends on politics, not management.
If you want to do it right, again, don't manage unless you absolutely have to. Your management always interferes with people who are trying to get their job done. Let them do their work, don't interfere. Except when they don't do their job (properly) or when something prevents them from doing their job, that is when you should be there to manage things.
Please read the following books: Getting Things series by David Allen; Smart and Gets Things Done and Joel on Software by Joel Spolsky; Eric Sink on the Business of Software by Eric Sink; and IT Manager's Handbook - Getting Your New Job Done by Bill Holtsnider (Second Edition). This will get you started. Never forget where you came from (roots) and try to keep some technical skills sharp. Keep your sense of humor and never be afraid of doing the right thing. You will be surprised how rusty your mad skills will get when you are reduced to typing words and numbers and not slingin' code. Good luck!
Here's your resourse:
Don't let HR hire ANYONE without you being at the final interview. They'll let anyone in but make sure the new people that get hired actually know what they're doing. That way when you say "go write this" they'll do it and it will work. If you don't do that and get losers that suck at programming, you'll end up doing your old job again when the people under you screw it up majorly.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
... the most important is the following: Address any issue that comes up directly and promptly, say what you think, and encourage others to do likewise. Leave nothing unsaid or unmentionable.
Everything else is obvious (think about your best bosses, how you'd want to be treated, etc.). But follow the above to the T. It will create immense respect for you -- a manager unafraid of addressing any concern that anyone has, someone who takes everything into account.
The best advice I can give is be clear, consistant, and explain yourself whenever possible. Make sure that the people you manage understand what is expected and why. One of the most important traits a manager can have is that the people under him believe what he tells them is reasonable, true, and trustworthy. And noone is smooth enough to keep up that impression indefinately unless it's true.
Well number 1 is "people skills" - now I'm assuming that you have them already but you need to identify + reflect on your strengths & weaknesses in this area. I strongly recommend Emotional Intelligence + Working with Emotional Intelligence - this is 2 books in 1 - the 2nd having case studies & examples. Remember you can't be what you are not but you need to gain a little more insight into yourself in order to be on top of others.
;-)
On the intellectual side ? Move away from "perfect" solutions- begin to live with having to make optimal, even sub optimal decisions to keep things moving. Remember often having 80% of something today is more important than having 100% next week. Learn to live with being "wrong".
Oh yeah, also when your developers give you a work estimate: multiply it by 2.5
Remember all of the things managers did to piss you off.
Now, with your experience, consider which of those things were actually helpful in developing your career.
Throw out the stuff that isn't, and follow the example your past managers set.
Good resources for you:
Some tips:
YMMV, and good luck!
I found "The Art of Project Management" book to be an excellent read:
r actice-OReilly/dp/0596007868/ref=pd_bbs_sr_1/105-0 051573-5986862?ie=UTF8&s=books&qid=1188342199&sr=8 -1
http://www.amazon.com/Project-Management-Theory-P
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
After reading lots of management books, attending management classes, emulating my own managers, I stumbled across the best management resource I've ever found: Manager Tools, http://manager-tools.com/ or podcast via iTunes.
I was in my 3rd management position when I found MT and started applying their advice, made all the difference. They've been where we are (engineering/technical groups), they speak our language, no fluff, and lots of very specific direction (with explanations). My staff was soon bragging to other departments about what a good manager I was, and lobbying other managers to try the same things.
Make sure you dig back into the archives, some of the first ones are the best. Memorable episodes: one-on-ones, running effective meetings, managing your boss, career/resume management, performance reviews
Well, firstly, I wouldn't ask Slashdot for advice. I mean, you must be desperate.
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 tell you!
I am anarch of all I survey.
My advice:
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 source) software, if you don't know it already. You'll want to have a handle on being able to quickly throw up various diagrams from human resource connections to network topography to class diagrams to stupid other things that somehow make any sense at all only when viewed visually.
4. Learn how to successfully deal with issues. I mean lots and lots and lots of issues. And I don't mean software issues. I mean people issues. Everyone has issues.
5. Learn the vocabulary of the people that you might now need to interact with outside of the pure software development world. I don't know your specific situation, but -- if applicable -- learn the vocab of project managers, finance, business development, product development, marketing (blah), etc.
6. If you're going to do a lot of true software development project management, consider picking up the "Head First PMP" book and reading through it. You might even consider getting certified as a Project Manager. Even if you are not specifically a Project Manager per se, I have found that a lot of the knowledge is incredibly useful as a VP of Tech for a small company.
7. Did I mention the thing about people having issues? Exercise, meditate, pray, smoke pot, drink martinis at lunch -- whatever helps you best deal with peoples' issues, because you are going to be smack in the middle with business on the left and software dev on the right!!!
Hope this helps!
One should never be surprised by a promotion into management. If you are surprised, then it means they haven't been giving you things to do to build up your management skills. For example, being a technical lead where you don't have any reports, but lead the development on a product. Or an intern to mentor (complete with an intern project), if your company has interns. Or give you one or two people to manage at first. And of course, management training courses.
If you're not groomed into the role, you are not ready. Management is not something to be taken lightly -- a bad manager can ruin the morale of the people under him, can get overwhelmed by the project management and career development that goes with being a manager, and just overall tank the project.
I would suggest "Good to Great" and "Question behind the Question." My current boss requires the second of his employees and uses the first for his own inspiration. Best guy I've ever worked for.
Sonshi.com has one of the best translations of Sun Tzu's The Art of War available anywhere. I've read multiple translations and this one is my personal favorite. Not only can you read the text, but each line of the book has its own thread on their forums, where people gather to discuss each line. To top it all off, access is completely free!
Print out the html pages, drop it into a report-cover, and you have an instant classic.
- DaftShadow
Can't recommend it enough really - it helped me plenty.
http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439
Therefore, I recommend as starters:
Book 1: Sun Tzu was a Sissy by Stanley Bing. Nuggets of truth awash in satire and dark office humor. It's an easy read and will help you keep your sense of humor when the inevitable soul crushing begins. ;)
Book 2: The first 90 days by Michael Watkins. Pretty easy read but covers how to deal with moving up - most companies are going to give you a trial by fire (I'm pretty sure my company uses a nuclear powered pressure cooker - I see people burn out almost monthly), and I suspect you're likely on your own. This book will help you make the transition work for you.
Good luck.
You have two ears and one mouth. Listen more than you talk.
I am assuming that you are talking about being a people manager and not a project manager.
An important thing I've learnt about managing "resources", especially for people transitioning from a technical background, is to focus on the business needs. Often this might mean that you go for the quickest bang for the buck, and not necessarily the architecturally best solution. This is an example - the point being if you really want to climb the management ladder, your whole outlook should change. You need to be customer-focused in your plans, in your thoughts and in your actions.
Know that you are now responsible not just for your deliverables, but that of your team. So while CYA is an important principle, you need to cover your team too.
I'm sure people will have plenty of advice to give you. At the end of the day, take it easy. Don't let the sound of your own wheels drive you crazy. All the best.
2+2=5 for very large values of 2.
ECT (Electro Convulsive Therapy) aside from the sudden increase in pay has a few other positive side effect like those nice pointy hair spikes.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
The number one tool I would seriously recommend to you seeking to become a manager or a better one is a site named Manager Tools (www.manager-tools.com). These 2 guys, who have experience with Fortune 500 companies share their experiences via their podcasts with great free advice. Don't take my word for it, check it out.
Managers who actually understand the technologies being used by their team are the best kind. When your team sees a technical problem with some decision or other, you can understand their concerns with a minimum of demonstration, and can also more intelligently evaluate the implications of their proposed alternatives (if not propose some of your own).
However, once you are a generation behind the times technology-wise, this could become a bit of a problem...you need to be able to reframe your perspectives to fit the new technological environment. Rules of thumbs and best practices from five to ten years ago are a good way to make your system an unmaintainable underperforming piece of junk today.
I find the idea of being a manager uninteresting and a downgrade in title. You take on more responsibilities and increased legal liability (bet you didn't know managers have certain federal and state legal obligations both for criminal and for civil courts). The pay difference does not offset this liability, in my opinion. And in some cases the pay for managers is less than top tier engineering positions. The thing is, not everyone can be a top tier engineer. But there are plenty of management jobs to go around.
Architect roles vary from extremely interesting top tier jobs, to mundane uninteresting jobs that involve a lot of meetings but little technical expertise. I've worked at companies where architects were there to basically negotiate between top 1% of engineering so that inconsistencies in the proposed design is worked out and that criteria for software meets the criteria for marketing and possibly hardware (if you're hardware+software company, like Cisco for example). criteria includes monetary budget, time to complete, select staff "vital" to the project, general staff allotments, and features.
It's valuable to have a small group of 1 or more people to balance and act as a conduit for all these groups with divergent interests, but often that role is heavy on the social interaction and politics and not so much on the technology. Sometimes this role is served by a manager like a VP of Engineering at a small company or a Director at a larger company. Sometimes it is given the title Project Manager but with the same role as I described, while the title Architect is reserved for the more engineering orient role of architecting the software, database, network, hardware or other technologies.
CTO as a start up is far more interesting. You get to make real decisions and you can dig into the product as deep as you want. Lots of meetings though, but it might be a fair trade to have a project that is "your baby".
“Common sense is not so common.” — Voltaire
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
Every time someone asks you a question that you don't already have an answer for:
Say "I don't know - but I'll find out."
The worst managers I've ever had uniformly made up bullshit just to avoid admitting that they didn't know something. They made my life miserable, and often caused substantial damage to the customers.
The next worst admitted they didn't know, but then didn't try to find out.
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.
Get some pet cats. Learn to herd them. And learn how to clean up the mess they make. Watch out for when they want to scratch or bite. And know that they are going to do a certain amount of napping.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
http://www.headblade.com/Merchant2/merchant.mvc?Sc reen=PROD&Store_Code=HB&Product_Code=10100-2&Categ ory_Code=creams
Learn to make hard decisions, even if they make you unpopular. It's what seperates plebs from management, the ability to do unpopular things for the common good.
If you mod me down, I will become more powerful than you can imagine....
One thing that surprised me most when I became a manager for a development team was that the "golden rule" doesn't apply. If you try very hard to be fair and treat the members of your team like you want to be treated, you're going to make all of them unhappy. Instead, you really need to spend some time trying to figure out what they want, where they think they're headed, and what you think they'll be capable of a few years down the road. It'll take a fair amount of time, but if you don't spend that time, you'll never be as good at management as you could be.
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 time anything happens, you don't actually get to do it, but you have to know what it is. Remember how you used to work for someone else who set priorities for you? Still happens, only your new boss has a more expensive suit. You will have all the responsibility of your old position, only without any of the ability to do stuff yourself.
There are plenty of management books out there -- it's hard to go wrong when learning the basics -- and they all pretty much emphasize the same things: effective communication, appreciate where your employees are coming from, demand respect for others in the workplace, lead by example, don't be a pushover, and foster a culture of openness so your employees aren't afraid to tell you what's wrong. If you're not sure how to effectively do any of the above, then The First-time Manager is a decent read. But if you're being selected for management, it's probably because your boss(es) have seen you demonstrate those qualities in the first place (unless you're in the military, where advancement is based in large part on factual knowledge that you will almost never use in management).
If you're staying in the same department (or just with the same company), the biggest problem may be the transition from a co-worker relationship to a superior/subordinate relationship. Some people may resent you immediately, and if they don't, they probably will at some point in the future, but if you demonstrate the qualities you require of them, you will likely gain their respect, even if you cannot maintain the same friendship you had. Of course, if you weren't buddies with any of your new underlings (and never, ever call them underlings), that makes things a lot easier.
That said, I hate being a manager/supervisor. The slight (in my experience anyway) increase in pay was never worth the added responsibility, visibility, and stress. My supervisor, for example (for whom I fill in when he's on leave) has 3x the workload, and only makes 3% more. Not only that, but if any of *us* screw up, he's the one held responsible. Middle management can also be lonely; too junior to be good friends with upper management, and too senior to be good friends with your subordinates, so it's good if you have friends outside of the workplace, or at least working in a different area. I'd say the experience is important and necessary -- especially if you want to do something like start your own business, with the possible exception of consulting -- but I've never found it to be a rewarding experience. Under the right circumstances, if I was a team leader or project manager for a creative project, I'd do it again, but in my current line of work, management = TPS reports and scapegoat.
https://www.eff.org/https-everywhere
...that happened to me once. I almost killed myself. There is a problem right from the start. Highly talented technical people make good money...so do management...so you seem to be someones solutions to a money problem. You better get used to giving yourself horrible deadlines and then hating yourself for it and talking shit behind your back. You better get used to not getting you work done and yelling at yourself and making you feel bad. Coders like to code and managers like to manage. Moving up to management is not something to take likely. It's like a painter being moved up to that ugly chick that sales advertising time.
-- A cat is no trade for integrity!
- What are their expectations of you ?
- What training and development are they providing to assist you to meet those expectations ?
Technicians tend not to make good managers. The skills and abilities do not always overlap (when was the last time you had to politic an application free of bugs ?). If your organisation is expecting you to make this transition, but have not/are not providing you with the appropriate traning and development opportunities to develop good management skills then you are moving on to shakey ground.The fact that you are looking for advice or direction shows that you have some concerns about your ability to step into this role. You really should discuss them with your new managers, and be prepared to face the consequences if this is a 'sink or swim' exercise and there is a chance you will sink.
www.manager-tools.com - that and google SHIT I'M A MANAGER PPT. I'm making the switch from mechanical designer to manager right now and those are the 2 greatest things I've come across. And yeah the extra hours are brutal during the transition when you'll probably have to finish off all your old projects.
Lasciate ogni speranza voi ch'entrate.
I can't believe nobody has yet mentioned Fred Brooks' "Mythical Man-Month".
It's not exactly a how-to book, but it gives important background as to how and why software management is hard.
It's also a little dated, so you have to read between the lines in some sections.
But it is a true must-read classic.
Three rules.
1. All the things you always said management should do, start doing.
2. All the things you always said management shouldn't do, don't do.
3. If you find yourself to be wrong about any of these things, fix it.
That simple. Management is all about using good sense and standing by your decisions.
You'll do well. Anyone who honestly tries to do well at management does.
Microsoft cheerleader, blue flag waving, you got a problem with that?
I'm sure you will find it handy.
is 'Leadership Secrets of Attila the Hun' (No, honest). That being said, I have been through the tech-to-manager trial before, and whilst at the time I thought it was what I wanted, I realised that I made a lousy manager, and it took a while to convince my manager to let me get back to pure tech. The main thing is if you find that you don't actually like being a manager, or are just plain bad at it, you will not be doing your staff any favours by staying in the role.
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
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!
Get one of these and keep it on your desk all the time.
This is probably the wrong forum to ask a management question :-)
OK, so now that we have the obligatory Scott Adams and "people get promoted to their highest level of incompetence" stuff out of the way lets take a serious look at this.
Here are a couple of books and a paper that may help you out.
1) Reframing Organizations: Artistry, Choice, and Leadership. By Bolman and Deal. ISBN 0-7879-6427-1.
This book looks at management from in pseudo-behavioral way. It covers the 4 primary frames of reference that we one can use to manage themselves, people, situations, their boss, etc. This is not a book about how management must dominate those below them. It is much more realistic. Of course old school MBAs might not grok it, but we are techies...we want information that works. The first few chapters start off a bit fluffy for a techy/engineer, but slog through them and then read the introductory chapters of each of the four frames. Then go back as you have time and read the remaining chapters of the four frames.
Remember its not engineering. It's a mishmash of organizational and behavioral studies. Much of it is based off of research from the social sciences and organizational research. In other words give it a chance.
2)Leading Quietly: An Unorthodox Guide to Doing the Right Thing. By Badaracco. ISBN 1-57851-487-8.
This book is great for techies in management rolls. Being a good leader is not about becoming a hero figure. Sure we read all the time about hero figures in tech, but 99.99% of the people that get stuff done are NOT them. They are the quiet core that make things happen and are agents of change. The only con I see with this book is that as you move up the corporate ladder one may need to become less quiet. Still, this book gives one food for thought and options that are especially good for introverts.
3) Also try to find a copy of "Managing Your Boss" from the Harvard Business Review. It is a short paper, but good advice.
If you are particularly worried you may want to look into a MS in Engineering Management, a MS in Management in Science and Technology, or a MBA with a tech focus. Most general MBAs are just that, too general, to be that helpful to someone in IT, Engineering, etc. Also make sure you go to a reputable school. It doesn't have to be top 20, but make sure it is a real college/university and has proper regional accreditation.
Successful resource management is about building and understanding relationships. If you are looking for a slogan, that is it.
It's about building, mediating, and influencing relationships, both with and between others, and leveraging those relationships to solve business problems.
If you have a difficult time emotionally understanding and relating to the people working with and for you, you will have a difficult time becoming a successful resource manager. You need to understand their goals. You need to understand what motivates them. You need to understand and adapt to the dynamics of the relationship they want to have with you!
Of all my readings on managing employees, I still find The Art of Demotivation to be my favorite. It colors my every interaction with executives and employees. Each person is responsible for their own psychological validation. Don't let your underlings burden you with their insatiable neediness. Show employees their cost to the company, not just their worth. Every cog can be replaced.
Pay a lot of attention to the financial system. In most organisations I've seen, people underbid on projects to get the work. As the project progresses it runs out of money so the only way to keep the show on the road by booking out work to another project that is earlier in its life and hence is still in the black. Eventually a meltdown occurs.
Anything that happens in your group that was bad is your fault. Anything that happens well you point out the employee(s) that did it. Hold those two things true at all times. It will show your superiors that you understand you own the success or failure of your department, and it will show your employees they can count on you to cover their back and to allow them to shine.
This doesn't mean you don't weed out the bad apples on your team. You do. One bad team member will drive good ones away and destroy both quality and productivity. However, their failure reflects on your ultimate failure to remove them earlier. If you don't own the problem you're putting your manager in a position to need to own and fix the problem.
And good luck. Management on any scale is a dog-eat-dog world where you are required to wear Milk-Bone underwear.
1) Learn to love the feeling of your rectum being regularly violated.
2) Learn to enjoy the taste of ass, because you will be kissing plenty of it.
when it comes to managing a team software project, you can do worse than trying to be religious about keeping everything well commented as a matter of policy. Keeps the team more productive in the long run, plus makes it easier for you to dive in and fix things yourself :) if something goes wrong. Which it probably will often enough.
Then, if you want to be really innovative, consider experimenting with better commenting through better employee division of labor. Get star developers do the coding, novices do the commenting and playing human knowledge base about the system, and get the most overall bang for the level of employee ability available.
Michael Lyubomirskiy, out to TiggerScript the web for better readability.
I think the most important thing any *people* manager can do is set the tone for the entire team. I highly recommend reading "The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't" (amazon link - http://www.amazon.com/Asshole-Rule-Civilized-Workp lace-Surviving/dp/0446526568). The world doesn't need anymore assholes in management. Good luck!
A lobotomy, of course. :)
http://alternatives.rzero.com/
Unless you're the CEO, a manager sits in between two layers: higher-level managers above, and lower-level contributors below.
To be a good manager, you have to stay in touch with, and informed by, both sides. Give both sides real consideration, make decisions that strike the right balance, and then make sure to explain to both sides how you arrived at your decisions using their input.
The biggest mistake many managers make is to only worry about pleasing the managers they report to, ignoring all the people under them.
Of course, this is just one piece of an overarching philosophy, which is: always make decisions that are in the best long-term interest of the business as a whole. Don't make short-sighted decisions that provide benefit now while making things worse later, and don't prioritize your own career and reputation over the health of the business.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Check out http://www.randsinrepose.com/
It's a fabulous blog about the process of development and managing developers. He's actually got a book coming out very soon that's an expansion of past blog entries, but the stuff on the site is excellent.
I see that there are quite a few people coming at this from an employee perspective, which is great. One thing that I've found that helps me *immensely* is to have high standards and high expectations of people, and to let them know that.
On the flip side, don't be a dick about it. Just make sure to let people know that you expect quality and after a little while (with some consistent nudging) you'll start getting it.
It makes life a ton easier as an architect and a manager when you have a solid base to work with.
There's some value in the book "I'm OK, You're OK" by Dr Thomas Harris. I wouldn't say it's "spot on", and I don't recommend getting fixated on it as "the Truth", but there's some worthwhile modelling of human relational behaviours in it. Follow on book is Eric Berne's "Games People Play". Again, don't get caught up into thinking it is "Fact" and it has some good ideas on disarming relational traps that arise between players.
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?
Or... How to kill someone with a bloody great sword.
...
You never know
Deleted
I've found joel spolsky's book helpful. It's not a comprehensive management book, but there is a lot of good advice that can be gleaned from his essays.
Remember all that stuff that you used to say you wish your manager would do for you? Remember, those things that your occasional good manager did?
Do those things.
If you are not allowed to question your government then the government has answered your question.
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 should check out the manager tools podcast at www.manager-tools.com. They have a lot of great manager advice and both come from the technology field. Good Luck!
If you are expecting something here, I don't know what to tell you...
Hey, congrats.
n quiry.asp?EAN=9781591391104
You're starting a completely different job, which means success will depend on COMPLETELY DIFFERENT SKILLS. Relying on the ones that got you there will not necessarily assure success in the new context. Read "The First 90 Days", by Michael Watkins, published by the Harvard Business School Press.
Here's the BN link:
http://search.barnesandnoble.com/booksearch/isbnI
I would highly recommend the weeklong training course called Situational Leadership given by the Center for Leadership Studies. I have been an engineering manager for several years now, having gone to various courses and read various books, and nothing compares to the value I got out of the Situational Leadership course.
In addition to the "how to deal with people" aspect, which is absolutely the most important thing, I might also recommend brushing up on your Microsoft Project skills by reading a book on MS Project. As far as more general books, you might look at Watts Humphrey's "Managing Technical People" as a starting point.
Dooooonnnnnttttt do it!
Table-ized A.I.
Seriously. I have been taken different management training whenever my company offers it, especially if it is connected with a decent college of some sort. It isn't perfect, but I found it useful. Especially any training that makes you think about how to communicate with other people. Even if you communicate well, the information really makes you think about how you communicate and adjust what you are doing. I don't mean in a slimly PHB way, I mean in an effective way.
5 years ago I moved out of network security engineering and moved into project management / direction. Considering the fact that I was getting a bit worried as to whether or not I would be able to constantly keep up with all the advancements, forever, I took that as a good opportunity to leave the hard core stuff to people who enjoyed it more than I did. (I was the best engineer in the company, but that doesn't mean there weren't people that had higher motivations than I did.)
Just my 2 cents, in no way is this complete, but here are a few tips. Management requires a lot of communication skills that you may or may not have. Even if you have them, chances are they're a bit rusty unless you were the type that preferred to socialize a lot at your work place. The up side to management is that you get to see the bigger picture of the projects in the works, rather than a micro-cosmos of whatever you are working on. The down side is that you're now responsible for the bigger picture as well, and will need to communicate with your developers as well as your own managers/bosses/clients.
Since you have a strong technical background, one up side is that communicating with other developers should be easier to do than someone that has no technical background. You will understand them more than others, and will likely be able to communicate requirements and "reasons" behind them more than another manager. The tough part is that sometimes you WILL be required to communicate why a seemingly bone-headed decision needs to be implemented. You'll also be responsible for communicating with upper management and/or clients and trying to avoid (and explain why) these bone-headed decisions. This is where the communication skills really need to be focused on. Don't lose your temper, stay calm and try to explain in a language and mind set that the other party will recognize and feel familiar with. Don't try and use "manager-talk" with engineers, and don't use "techno-mumbo-jumbo" with people that aren't familiar with it. When you talk to clients and/or upper management, you will soon learn that these people can easily get frustrated when they can't understand some concepts. Since you were a programmer, you're familiar enough with the technical aspects of things that even if you come accross a term or two that you don't recognize, you can still make it out of context and look it up later, which just won't happen with others. They will lose track of what you're talking about. The worst part is that some will PRETEND to understand, which will cause a lot of trouble down the line. "What?? You said you understood! OF COURSE implementing XXXX will cost YYYY% more time and dollars!" Don't patronize though, that pisses off everyone.
Another thing I would strongly suggest is to NOT get your hands dirty with non-management technical tasks. It's an easy trap to fall into. Since you have the technical background, you WILL be tempted to do some things yourself instead of assigning another programmer to do. Sometimes it will be because you're short on time, other times it will be because you understand it better than anyone else in the team. But, you are no longer a programmer, and you will not be evaluated on the extra time you spent coding something. You will be evaluated on how efficiently you assigned and utlilized your coders. Again, this is likely to frustrate you sometimes, especially when a coder comes back with something sub-par that you KNOW you could have done better, in half the time. Eventually, you'll get used to this, but for starters you will need to make conscious decisions.
Don't feel like you've been left in the cold by becoming a manager. A lot of tech people feel comfortable coding, and when they're not, they feel like they're not contributing. This isn't true though. Projects don't come together with coders alone. There NEEDS to be management of some sort or another, and you're just as important as the coders are. "Manager" isn't a dirty word. Well.... not inherently.
And
The best thing you can do is to not stay stuck at your desk, talking to the world via email and IM. Get out there in cubeland and talk with the people you are responsible for. Go visit people where they live.
by Bracey, Rosenblum, et al.
I'm not a manager, but after reading that some years ago, on the advice of a friend, I became able to quickly spot the type of manager with whom I most enjoy working.
somebody at your company hates you.
Understand that emails will not cut it.
You need to walk around and talk to people.
Understand that seemingly intelligent adults will sit and do nothing when they just need a 60 second answer.
Work the process. Document things. Push big decisions up to the business.
Don't overwork your people.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
1. The single biggest change is conceptual. Your success no longer depends on what you produce as an individual. Your success is measured by the success of those working for/with you. Within the limits of what folks higher up on the food chain give you for resources, your role is to ensure those resources are used in ways that allow those you manage to succeed. And be careful not to get too hands-on. In a new situation (management) it's awfully tempting to ease the discomfort as a newbie manager by falling back onto something you know you can do well.
2. People will come and go, so ask yourself: What can I do to try to ensure that if this individual leaves, he or she will look back on their time here as one of the most growth-filled, if not rewarding, period in their career. One of the highlights of my time as a manager was hearing -- via an intermediary -- that so-and-so wanted to send along his regards, because during the two years he was with the organization, I had given him far greater opportunities than he had expected to test and expand his capabilities. That's your ultimate performance review.
3. Clean off your figurative glasses every morning before you walk in the door. I've seen good people overlooked for new opportunities because at some time in the past they made the mistake of slighting (real or imagined) another senior manager. But that slight was all the upper-level dude could remember. This means you become an advocate for your team members when they have made genuine progress that the next boss up hasn't tracked.
4. Look for little ways to show genuine appreciation for your team's work, especially on projects where they put in awful hours to get the job done. And be specific in what you thank each for. Otherwise, they think you're giving them a pro-forma pat on the back with no real knowledge of what they went through.
5. In the end, you're their manager, not their closest friend, and you'll have to make some tough, even painful decisions regarding their careers. But you can still treat them with respect and even compassion. Treat them the way you'd like to be treated if they were your boss. Because at some point down the road, they very well could be!
I'm not the OP but here's a question and a statement.
"Don't speak for the rest of us"
And when slashdot says "government is this", "business is that","consultants are","Certificates will","managers are" or even "people are idiots". Aren't they guilty of the same thing you're accusing the AC of?
"particularly when you don't have the minimal courage required to associate your whining comment with a Slashdot handle. "
Many of the comments mentioned were done under a handle. So much for a sign of quality.
As someone who alternates between technical architecture and management I can sympathise with where you are going. My 2c worth
:-)
h tml
- developing people is far more interesting and challenging than developing solutions but is also 10* more frustrating.
- you can either manage or you can architect. You can't do both for the same project but you can do both roles so long as there is someone else doing the other.
- communication is all. Remember that it is up to you the communicator to ensure the person you are communicating to understands. Get them to paraphrase things back to you, maybe in the form of a first steps.
Of course in a classic catch 22, this doesn't apply to when your boss is communicating to you
- delegate but remember to set appropriate check in points and do so. Set appointments with yourself to check in on how tasks are progressing.
- say thanks for people who have done their job, not just for exceptional work.
- block out time in your calendar to do work.
- listen to what is being said about your team.
Good luck
PS I also like Gerald Blair's management thinkings. http://www.see.ed.ac.uk/~gerard/Management/index.
The best thing any manager can do is foster trust among team members. In order for a team to be truly effective they must trust each other, they must trust their leadership, and their leadership must trust them. Without that, your team and project are destined to fall short. Without trust, team members will lie, withhold information, mistreat each other, resent each other, and ultimately they will not be accountable for their actions. All of that results in poor efficiency and loss of quality in your product, whatever that may be. Your team doesn't need to be friends with each other, but they do need to trust each other's abilities, and have respect for their co-workers, as well as you the manager. The best way to get that is to be the example. Don't micromanage everything. Trust your employees to do their job without your help, and provide a sincere reward (even a simple "well done" is enough) when they do well. Lastly, a really good manager has two qualities that most people lack. 1) Listening skills. Managers who do not listen to - and appropriately act on - their worker's concerns garner resentment from their workers, which leads to a lack of trust, which leads to a lack of respect, which leads to a lack of accountability, which leads to poor working conditions and reduced efficiency. Good management means keeping all of those dominoes standing steady. 2) No ego. A good manager does not think of himself as a superior, even though his job title implies it. A good manager is always objective, and never allows his ego to bias his decisions. Learn to listen to your workers when they really do know more about a subject than you (which will be the case many times). If you're constantly undermining a worker's suggestions because you think you know more than them about their specific area of the project, you will lose trust, then you will lose respect, then they will lose accountability, etc etc you get the picture by now. Being a manager is easy. Being good at it is really hard.
two words: lobotomy
They're seldom trained to do their own jobs.
This is doubly ironic because if they were trained, they'd know that their number one duty is to make sure that everyone who reports to them is capable of doing their job properly.
It's a problem that tends to be inherited - if you were badly managed in your day, then you'll probably become a bad manager, because that's the example you've got to go on. Formal training helps to break that cycle.
In short: get training. Even if you have to pay for it yourself, you'll thank yourself later.
visit him often.
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
Check out the Manager Tools Podcast on iTunes. I've found it to be very well presented and often 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.
Engineering is the art of compromise.
I would even recommend financial account as well. Accounting (financial and managerial) are the basis for understanding any company's finances small or large. Managerial accounting will give you insight into how to deal with upper management and why the do some of the awkward things they do.
Companies don't want "managers", they want "project managers" - and what they look for is the PMP certification. Yes it costs some $$$ to get, but consider this: the average salaried PMP across all industries earns $150k (according to PM magazine). A contract PMP in software/IT can expect $125-175/hr. Ever done any SAP work? Then bump that up to $250/hr.
I read something recently that nicely summarizes leadership in general. Paraphrasing: The measure of a leader can be found in the eyes of his or her direct reports. Concise, and so true! The context of the quote was a book on military leadership, but it applies to the corporate arena just as well.
As a manager understand that part of your role is to be a buffer and a translator --You must always be looking both ways and translate and restate the information and requirements going both ways: for your management you need to make them understand the challenges and issues of your staff while protecting your staff from unreasonable demands and undue interference from above; for your workers you need to keep them focused on obtainable goals, shelter them from the unreasonable demands of management, cover for their weaknesses, and exploit their strengths. Your workers are your assets, you need to spend a lot of time tending to them, making sure that they are getting rewarded for what they do, and motivated to keep doing it. As you move up the food chain (yes it's a hackneyed simile, but it's appropriate), you need to realize that part of your job is to resist and even push back on management when things can't be done the way they want, or in the time they want. Some of these issues are technical, some are emotional, some are just rules of physics.
As an architect, your role is mostly technical. This is in direct conflict with your managerial role, and is therefor quite difficult to cope with. To resolve the differences, you need to balance the needs of product with the abilities of the people. You need to make your management understand that you are doing conflicting things, and that you may be arguing different points based on what role you're in at the moment. For you workers you need to limit your design goals to what is deliverable, features are a wonderful thing, but you still need to ship on deadline.
I expect that you actually have a third role as well - supervisor. Heaven help you if you are in this triple trap. Use your managerial authority to get a supervisor to deal with the personnel issues of your workers - you can't be their design guru and their disciplinarian/fairy-god-mother at the same time.
Managers manage products.
Architects design systems and software.
Supervisors supervise people.
Recursion: To curse repeatedly.
18 months ago I was an employee. Not IT but still a skilled technical role. Then I set my own company up and started from scratch working for myself. Now I employ 9 people, all of whom are technical working as what I used to be.
The biggest challenge I found was trusting people to be able to do a job well enough. When you think you know how to do something it is very very hard to allow someone else to do it. As they will never quite do it the way that you do it and if they screw it up you get roasted (for me it was the company could go belly up).
Learn to trust the people who report to you. Learn to trust them to do a good enough job without you having to check on them. If you can do this most people will perform better.
Finally don't play at being a manager. By that I mean don't try to become what you think a manager should be. Just be yourself and be there for the guys you are to look after. Its a funny thing - in my role people try to steal from you all the time - its part and parcel of the industry. When it used to happen to me it never bothered me. When it happens to one of my guys I get so so so angry. I actually have had to take walks out of the office before just to cool off because I am so totally protective of them.
I'd recommend the book One Minute Manager by Kenneth H. Blanchard and Spencer Johnson Fast read - you'll finish it under an hour.... and really truly insightful. Totally non-technical - just plain and simple management. Probably the most important book that I can think of for anyone going into management.
Believe it or not, as a code monkey, you probably have better technical skills to handle management, than most of the management types around you. Math and sorting, are used in most management decisions that need to be made. That being said, you may need to develop other skills such as organizational, interpersonal communication, decision making, risk assessment, etc. The existing managers are your best sources of information as to what may be valued in management by your organization.
Have lunch with your management peers and superiors. Listen carefully for things that they complain about the organization. Also listen to them boast about their own successes. I hate to say it, but your success as a manager will be to take the problems of the organization and fix or work around them. You'll also do well by being better than they are. This in turn will be rewarded with increased scope of management. Eventually you'll be in a position to manage managers.
Next, have lunch with your team. From a purely practical standpoint, the best manager, get his team to perform the most efficiently. Get to know your team, what makes them tick. Use this knowledge to lead them. Celebrate their successes at least as often as you correct their transgressions. I prefer to lead by example - eg. if extra work needs to be done on a project, they see me working 2 extra hours for every extra hour I ask for.
Expect 10-20 percent of your time to be somewhat 'wasted' with routine stuff such as approving time sheets, vacations, people issues, budgets, planning, and providing documents to your boss that will never be used for anything.
I recommend materials by Steven Covey for general organization and decision making skills.
Good luck!
Someone once described management as "the art of making and prioritising lists". I'd also add _communicating_ the lists.
. gov/19960002194_1996102194.pdf). If you cannot state what it is that you and your team need to do to both be finished and prove that you are finished you are lost.
The other half of the job is sheilding your management from your team and vv. While ensuring that no-one is suprised - management, team or customer.
Get reading - both dead tree (dynamics of software development, mythical man month, peopleware, dibert) and online (eg. rands in repose).
Start learning "systems engineering" - the NASA systems engineering handbook is available free on line (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa
Systems engineering is sometimes described as "engineering management defined so that MBAs don't do it". For good reason.
Start learning about risk management (AS/NZS 4360:1999) and Earned Value Management Systems. And basic accounting principles (esp. cash flow and ROI).
Concentrate your tiny, tiny amount of remaining technical time on ensuring that your team is not stuck in a dead end or going off the path - and do so via discussion and review of code/documentation. At all costs, avoid doing any "real work" (this can change later).
Every week, discuss with your team
* what you were going to do last week vs what actually happened
* what you are going to do this week
* what risks and issues exist, and what _you_ are going to do about them
Every "reporting period", report to your boss
* what your team did or didn't achieve
* what the targets this week, month and quarter are (and when they are likely to be done)
* what risks ($ x p()) exist (including any current "issues" that may need his/her input)
* what issues you want your boss to deal with
This is a pain - and even for a very simple project will take 1/2 day per week. But if you don't do this you are dead.
-- Butlerian Jihad NOW!
Read this blog: http://www.randsinrepose.com/f tware-Engineering/dp/159059844X/ref=pd_bbs_sr_1/00 2-5507769-8385647?ie=UTF8&s=books&qid=1188351151&s r=8-1
And this book by the same author: http://www.amazon.com/Managing-Humans-Humorous-So
I can't speak highly enough of this book. For years I've been struggling through a similar type of dilemma (systems administration to technical director), this book i bought recently rules.
http://www.managinghumans.com/
Good managers don't order engineers around. They use the power of their position to provide extra assistance, guidance and support that is otherwise not available directly to engineers just trying to do their job.
If you have survived 15 years as a code monkey, then you have had your fair share of successful and failed projects and you have met pretty much the whole spectrum of manager types in the industry. Simply try to do as the managers from your past that you consider successful (or less disastrous).
Whatever you do, try to remember that one of your most important jobs as a manager is to act as a shit shield so your employees can do their jobs without outsiders screwing with them.
Pedro
----
The Insomniac Coder
there are a great deal of subtleties involved.
You might transition easily but will you be effective?
A mentor can help you see what battles are not worth fighting and what battles are and why...
It doesn't have to be someone in your company either...
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
The reality of management is that it's a game where winners move up and losers are destroyed. Winning the game requires forming a team that moves up with you as well as undermining your competitors. Unless you've recently acquired a "friend" in management, you're probably not really joining management. Maybe a manager created an architect position to move a supporter into, but rival managers have team up to block the move with a non-player. Maybe their following the Roman model for dealing with problem people by "let him be promoted and removed." Maybe your technical work is being obsoleted and it's a sympathy position. Anyway, if you want to know how management really works, I recommend a movie called "In the company of men."
Peopleware is by far one of the best management books around. Everything by Spolsky is gospel :) Death March and Waltzing With Bears are also great reads.
I recommend that you join the International Association of Software Architects. The fee is nomial and you will meet others who are in a similar position. (See www.iasahome.org)
I second the idea of looking for a good mentor. My HR director has been a great resource as someone with whom to vent, to discuss open issues, give advice and to guide me when I'm in danger of making a mistake. A lot of HR directors are mired in managing the firm and department but would much rather be mentoring and advising staff, listening to issues, etc.
Meet with your HR director and spend some time yapping about minor issues. Let them know you value their input and welcome their assistance as you transition. Try to establish a good working relationship before you have a major issue to address.
Good Luck.
If you have not done so, read "Mythical Man-Month". Its dated, but oh so good. Also, "Peopleware". "Joel on Software" is really good as well. Now you'll be responsible not for code, but operations.
The other paradigm shift is you have to have/develop people skills. Remember people are people and not resources. And people are very illogical in the majority of things that they do. Their situation will begin to differ greatly from yours. You'll care more about deadlines and schedules. You'll be pressured to work your subordinates harder. I fullly reject the idea of pressure in the conventional management sense - instead go with goal alignment. You'll get better results and people will be happier.
There's so much more, but I'm still figuring it out. Just don't fail to realize that politics and tact has become so much more important in your day-to-day. Computers don't care about that kind of stuff so you've probably not had to deal much with it, but it is the largest thing you have to learn.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Make some contacts with other managers (your previous manager is a good start) and talk w/ them about what they think is important. Mentoring can be a very useful tool.
If nothing else, pay attention to what they have to say about the people that you're going to start working with. Part of the job will be handling people's personalities. Other managers may have some insight into the new people you will be working with.
To All. Be true to thy self. That is how you change from a SSE to manager to director in a year. I have learned management from the fire hose by taking my 5 best and 5 worst managers, then emulating the good ones and not doing what the bad ones did. Along the way here I have learned that there are just times you have to tell your peeps this is the way it is. And some times you can get their buy in. At the end of the day/week/month/year....Be true to thy self. Treat others as you would be treated, and remember statistics are like a bikini. They hid what is vital and show what is suggestive. All the rest is just noise.
Glib's "Principles Of Software Engineering Management" should be your first book.
This is an easy read and is the only one I keep going back to.
The "Leadership Secrets of Attila the Hun" was funny and actually useful.
"The Mythical Man-Month" is a great book in that it really shows there isn't such a thing.
There are a few others worth your time but I'd say go with the Glib book first.
1) Your success has nothing to do with your performance, and everything to do with those working under you.
That's all you need to know. You are there to keep the machine that is your team moving along and out of any train wrecks. As soon as you start to try and do some of the teams work yourself, you've lost because
Your team is better than you are at it (if not right now, they will be)
That's the long and short of it. Managers are there to manage the work, not do any themselves. Hell, I was once a great retail manager once. I was a horrible salesman, and I hated all of the retail customers, but I knew how to build a team and facilitate their success.
Debugging the Development Process: http://www.amazon.com/Debugging-Development-Proces s-Practical-Strategies/dp/1556156502
Peopleware:
http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439
And think about those managers over the course of your career whom you've enjoyed working for, and felt most productive under. If you can - ask them for advice. If any of them were, or are, in the same company - that's even better.
Finally, many companies have "intro to management" courses offered by HR - sometimes they're mandatory when you're promoted into a role with direct reports, sometimes they're not. Take one, either way. You may not learn much, but at least it should give you a sense of the "management process" in your company from a perspective you may not have glimpsed before.
Although you didn't ask for them, since I was in a similar position a few years ago, I'll offer a few specific suggestions and observations.
First of all, your management responsibilities won't just do themselves - they'll take time. Seems obvious - but I've seen (and worked for) first time managers who figured they could just go on writing code, and the rest would "sort it self out."
Second - you have two bosses - the people you work for and the people who work for you. You're accountable to each of them for different things.
One major job is to facilitate communication in both directions. Make sure the folks working for you know what's expected of them, and how that contributes to the company goals/direction. Similarly, you need to make sure the people you work for understand what your team is doing - what it's challenges are, what it's successes have been. And don't neglect communication within the team. You'll likely eventually be called on to smooth ruffled feathers, or sort out conflicts among your direct reports. It's not fun, but it's part of the job.
Another key role is facilitator. Get obstacles - technical, organizational and otherwise - out of your team's way *before they're stymied by them* so they can execute.
One way to do this is to make sure you talk to everyone working for you regularly - at least once a week, more often if the environment is "highly dynamic" (i.e. sh*t changes quickly). Find out how they're doing - and, most importantly, what they need from you so they can get it done.
If your management role includes "pay and review" responsibilities (as opposed to "just" technical leadership) - get to know the appropriate folks in HR. Most companies have a pay grade system that basically defines compensation latitude - learn it, and learn where your reports are on the scale.
Depending on the make up of the team, and the "formality" of the environment, this can either be grabbing coffee together, or having a more formal scheduled one-on-one.
Keep notes on these meetings - and encourage your reports to do the same. Note commitments made, those that are made good on, those that aren't. When folks volunteer to take on additional responsibility, and when they shirk the responsibility they have. When you end up writing reviews, these notes are useful to justify pay rises or lack thereof.
Finally, one of the hardest things for first time managers is the transition from "one of the team" to "running the team." It's especially tricky if you manage anyone with whom you have a personal relationship (friendship, dating, etc.) The generally safe thing is "don't." But my experience is that overlapping relationships are maintainable, but only with early explicit agreement on both sides.
I've worked for, and managed, friends a number of times over the years - and the very first conversation, either way, has been something like:
"we're friends, and I'd like to stay friends, b
...As a manager, I believe my #1 job is to protect my employees from the shit that tries to interfere with their ability to get the job done. The more I can allow them to focus on their goals, the more successful we are. Whether it's keeping the CFO out of our weekly status meetings, or keeping the end users from calling my best developers when they can't remember their passwords - it's my job to remove roadblocks (competing projects, lack of funds, stupid requirements, etc) and to give them the focused time they need to solve the problem and deliver the solution.
IMHO one of the worst mistakes an organization can do is expect someone to be a technical contributor AND a manager. The technical contributor needs to be allowed to focus on the problem and the solution. How many times have you been deep into a coding session, and then had all the threads in your brain flushed because some dickhead stops by your office to ask about some other project? Most of my day is filled with switching from one topic to another - either by phone, email or in meetings. I'm lucky to get 30 consecutive minutes out of a 10 hour day devoted to a single topic. That's my job - field and filter all that crap into a consistent plan that allows my people to actually do the work. If they need to depend on me to hit a specific delivery date with my own contribution - they are in deep shit!
The fact that you would think to turn to Slashdot for this kind of advice tells me that you won't have to worry about your new position for very long.
Modestly, I'll recommend the Second Edition of our book: "IT Manager's Handbook: Getting Your New Job Done". On Amazon, B&N, etc. (Morgan Kaufman Publishers, ISBN-13: 978-0123704887) It covers topics you'll face every day such as open source, wireless, handhelds, outsourcing, offshoring, etc. It has lots of stories from people who are out there in the corporate front lines right now. And if you make the jump, send me your story - my email is in the book.
Good luck.
Bill Holtsnider
I suggest Despair.com go to the movie section and watch the managerial videos. Those should set you up for success!
Inane Comments are Generously Disregarded
I too went through the change from hard core sr. techie to mgmt a few yrs back. Probably not unusual for many starting off as techies, I was (and still am) not the most people oriented person so it was key to find some material to stir the part of the brain to lead people. While this may not seem intuitive at 1st, find some good athletic coaching books. Not the egomaniacs, more along the lines of, say, how John Wooden developed the UCLA Bruins. After some time in the job and realizing your role is really to make your staff successful (not just use them for your own self interest) you'll understand why the athletic team coaching approach can help. I think the other advise on this thread is valid too, ie business courses and the like... take it all in, observe, be open minded, appreciate your staff for the value they truly are.
Written for kernel managers but applicable to other areas.
Being a good manager is about using Leadership and Influence skills, proper delegation and time management and being aware of power equations. A knowledge of Negotiations too helps. But the most important aspects are taking care of the team and motivating them. Some good books that you can try are:
1. Influence: Psychology of Persuasion by Robert Cialdini
2. Shackleton's Way: Leadership Lessons from the Great Antarctic Explorer
3. Getting Things Done: The Art of Stress-Free Productivity
4. 48 Laws of Power
5. Execution by Larry Bossidy & Ram Charan
6. Getting to Yes, Bargaining for Advantage
Hope this helps!
Cheers,
D.
In God, I trust. On all others, I used dsniff.
Your company would probably be happy to pay the $99 for you to join the ACM, if you're not already a member. They've got a slew of learn-when-you-have-the-time online courses (now from Skillpath) that cover a lot of management and business turf, as well as tech. Some of the content may make you want to shoot yourself, but whenever you get that nagging feeling that you didn't handle a situation just right, or want to prepare for something you know is coming, you can pick a topic, do some drill and kill (um, "online learning"), and at least get another perspective. I agree with all the advice here about listening to your people, finding mentors, and trying to crack a book, too. An ACM membership has a lot of legs, though, and makes a nice add to all of that.
Nope - I don't work for the ACM!
What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith with Mark Reiter. Good for identifying and working on weak points in your behavior, e.g. impatience.
Additional plugins are required to display all the media on this page.
Get ready for 400 juvenile posts about PHBs. Odds are someone with 15 years of purely technical experience (code monkey, no project lead experience) is going to crash and burn, not because you're incapable, but because you'd already be leading after 15 years if you had the inclination.
If you do want to suffer through the worst, remember loyalty is key the further up the food chain you go... at least upward loyalty; don't necessarily expect the same in return. You're only as good as your last score.
Get Pink Floyd's Animals. Study it.
Not true! If it's a two-stroke. Four-stroke and totally bone-dry, contains no lubricants at all? I'd have to put money on how many revolutions you'd get before it just froze. Couple thousand?
IOW: not buying the engine analogy.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
Executive summary (ha ha): meet with your people one-on-one every week, give them lots of feedback, and coach them where they need to improve.
I just made the jump to management myself, and this is one of the best resources I've found. And it's free.
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.
Do you have some free time in your hands? If so, search for management training. I have a Bachelor's in Computer Science and I'm now completing my Master's in Management. It's useful, but in order to benefit fully you have to read research papers from business academic journals and not just learn from the university book or lectures. I suggest exploring the distance learning programmes offered by Open University. A programme of study will help your mind get used to the vocabulary and basic ideas and conceptions of management, so you will be prepared to seek more knowledge yourself during and after the formal study.
You can also register to a professional association focusing on management. I am a member of the IEEE Engineering Management Society and I read their and other journals, and I am also associated with the Chartered Management Institute, in addition to many engineering and computing societies (ACM, BCS, IET...). I actually combine business consulting and computer consulting in my work as an independent contractor, and I have also found that management and business consulting in general is way more profitable than technology consulting, so I would surely recommend every techie geek to get familiar with basic business jargon and concepts. There are endless opportunities for IT people who have a good grasp of business out there.
To be a good manager you have to focus on both your business processes and your people. Design good processes for your orgranisation. But merely focusing on processes isn't enough, as you need capable and motivated people in order to implement them. That's why you have to be a people manager as well. You must make people believe in you and trust you. You need to actively help your people succeed in their roles, not just demand from them to do something. If you have firing powers, make sure everyone is aware of them, but use them sparingly and with great care. If you are involved in hiring, make sure you have a good grasp of human psychology and always ask potential hires to write some code. If you communicate with clients, keep in mind that the client has a problem and needs a solution to it, not a technology or a product. Even if you use the best programming language, you will fail if you didn't understand what the client wanted in the first place. Actually the ability to correctly figure out what a client wants is what distinguishes a programmer who can work independently (self-employed) from one who can't (and therefore needs to be the employee of a company or cooperate with others in a firm). It's difficult because it's like having to work two brains at the same time (a techie brain and a business brain with lots of psychological empathy and listening skills), bit it's possible and those who can do it see great rewards. Keep in mind that since you work for an organisation you will have to understand your boss's vision as well, since you are being asked to implement it.
The problem for businesses is that a large percentage of programmers who are capable of interacting with clients and thinking about business leave to work alone when they realise their true abilities, so companies, especially SMEs, are always short of good middle managers. If you can code and handle human issues at the same time, it's good to realise it early in your career. If you are only one-sided (only code or only business) then you can work on it and improve.
Improving your management capabilities can happen in two stages: Since you are a developer I assume you are well-versed in analytical thinking, so you can start by learning about business processes. After your brain starts thinking in business terms, begin stressing it with people management issues and some psychology. Enroll to some training programmes, read independently recent management research (most research papers that weren't written just to grab a grant have something u
Best advice I got when I was faced with this same developer to manager thing years ago. Unfortunately the two skill sets are often not in the same person, being good at one often means you'll be crap at the other. So the advice I got from a mentor at the time was 'Manage the White Space'. Know what everyone is supposed to be doing, make sure they are doing it and manage all the bits in between their jobs so they can continue to do their jobs wihtout hassles. All that takes is common sense. If you don't have common sense you're screwed. Worked for me. My staff don't hate me and my managers don't think I'm an idiot (yet), so I'll take that as success.
Congratulations, you're on your way up a different ladder. As an architect you're arguably at the "top" of the technical ladder (and pay scale). Your first management job is an entry into a whole new ladder--if you want it. Be very aware though--this is a different job. I made the jump several years back much as you described and am now a global VP.
The biggest change is that you no longer do the work as an individual contributor. You manage those who do. Sounds simple, right? Biggest problem is that unless you let your tech skills get rusty (NEVER let this happen!) you can probably do many of your guys' jobs better/faster than they can because of your experience. Don't give in to the temptation do to the work yourself. That's no longer your job. You don't get graded or bonused on how well you write code. Now you get graded on how well your team performs as a unit. I can't tell you how frustrating it will be the first time you catch heat for a project in trouble that you just *know* would have been fine if you had been writing code yourself. Don't take it personally--its not a personal attack. Explain your action plan and how you've allocated your resources based on the management team's communicated priorities. Sometimes all you can do is all you can do. Sometimes, on rare occasions, even PHB's are reasonable people if you explain yourself.
You'll have to get used to communicating messages to/from senior management who doesn't know anything about technology, and frequently has zero patience for it. You'll get exposed to different decision logic that now you'll have a growing input to influence rather than just have things land on your head. Largely this is a matter of higher perspective. You'll now be more concerned about a broader scope than just a single project and may choose to make resourcing and priority decisions that won't make sense if you were a non-management coder focused on a particular task.
Here's why its 100% critical you always stay sharp technically:
First there are a lot of non-tech managers who like to poke their ignorant noses into technical matters (not to mention vendors, etc.). Staying sharp means you will always speak with calm authority and never doubt yourself when speaking to your area of strength. In other words you can't be BS'ed. Secondly your team will respect you. You need to build respect like money in the bank for a day you might need to make a withdrawal. Your team needs to know you represent their interests when you meet with your management brethren. Win some battles for them--you'll need the political capital. On those occasions when your job is to deliver a difficult message down the tree your team will at least know you aren't vacantly parroting a message somebody read in Infoworld. They will at least know you understand the implications of what you're saying.
There are plenty of good courses, seminars, and certificate programs you can plug into at universities and colleges in your area in their school of management. I'd pass on the books-de-jour. They'll just preach some 12-step program to overnight success that everyone will see as plastic and methodological. Be yourself!
Give your new career some time. Junior level managers are basically the coffee-getters of senior management just like entry level programmers and get the crap jobs as any newbies would. Stick with it, gain respect, be a team player without being partisan and you'll find your influence and voice growing.
If after a while this isn't your cup of tea there's no shame in re-entering the tech world as an architect.
Good luck!
Lots of useful comments above, some not so useful, too. In my personal experience, one of the hardest things I've had to overcome in my transition from a technical subject area expert to a manager was the desire to try to do all the tough work myself. Learn to delegate, let others do the work, play to their strengths and don't be afraid to give them assignments they might not yet be ready for - they will rise up to the occasion (most of the time, anyway).
Good luck.
I have over 25 years experience in IT, moving up through the ranks as the primary go to guy for the hard technical stuff to my current role as an IT VP responsible for corporate architecture.
When I was first given the opportunity to be a manager of a large group, I continued to get into the weeds of issues and personally work to resolve them. If members of the team were falling behind, I would stay longer hours and solve the problems, on top of my managerial duties.
During my review, my boss (the CTO of the company who also had worked his way up through the ranks) gave me a piece of advice that has stuck with me all these years: Sometimes your just going to have to let people fail.
If you're a technologist, it goes against your nature to let anything fail. You'll want to bail everyone out, and you'll find that you just can't.
The other lasting lesson I learned (from this same boss) was that you as the leader step up and take responsibility for any issues that are caused by members of your team. You don't tell your bosses that the fault lies with a member of your team, you take it. Then you deal with the team member yourself, keep in in the family so to speak. Basically remember the saying Share credit, take blame.
When problems arise, your job is to solve them, not assign blame. When everyone is pointing fingers you step in and take control, organize to solve the issue and get it fixed. Deal with the causes after the problems are fixed.
It is not an easy task. The people you work with today you'll be expected to manage tomorrow, and some of them will not like your decisions. You'll now be the clueless enemy. It doesn't mean you can't have a good relationship, but never forget you now will be responsible for their performance reviews, which affects their careers and pay. And something most line developers don't recognize, you have the responsibility for not only managing your team, but also your bosses. You now have to manage up and down.
Some of your team may become stronger in some technical areas then you, so you'll definitely want to listen to what they say, but when all is said and done, you make the final decisions. Healthy debate is good and leads to better results, but you'll have to referee.
Don't feel threatened if you have a team member that actually has better skills than you, or one that would even make a better manager than you. If you find someone like that, encourage and support them. That has always been my philosophy, to find someone capable of replacing me. Interestingly enough that helped my career grow because my bosses always knew that they could move me to something new (maybe a team that was struggling in an area that was new to me, maybe a new business concept that needed proving out) because they knew there was someone on my team capable of stepping up and taking over. I have been given some really awesome opportunities because of that.
And yes, you can expect to long for the days where you stayed up all night on Jolt and pizza and through a heroic effort, delivered the project on time. But, it can be just as exciting to work with a good solid team, helping to mentor junior staff members and realizing that you have more to offer than just solid code writing skills.
Congratulations and good luck to you.
Find out "How to become number one politician?"
Slashdot = Sarcasm
I was a tech lead for many years and I don't put to much value in most of the upmodded comments I've read here. Its fairly clear to me that they were posted by people who are not managers, but instead are posting fantasy wish lists for their own manager.
Reading books is not going to do you very much good. Management is about social interaction, and reading is not a social activity. Instead, you need to practice actual social interaction. However, I do agree that the "how to win friends and influence people" is an insightful read.
Here are my quick tips:
Realize that management is not about control, it is about influence. The harder you try to control people, the more stubborn they will become. Instead, your job is to influence their behaviors, not dictate them. You can only influence people when they know and respect you. They will only do this if they feel you care about them.
Talk to all of your reports everyday. Be interested in them and their assignments. You cannot manage by memo or telephone.
Regular meetings are important. On the surface they are about communicating details and process to the team, but really they are about socializing the team members. Over time meetings influence people to bond into a team of people who will identify with the group. Of course, keep meetings short. But also try to be sure that everyone gets a turn at speaking their mind; some people will have to be coaxed to talk (and some made to shut up). Remember, meetings are really social events, not technical events, and you are the MC who keeps things moving along.
Humphrey has written quite a few books on software engineering and management, and you would do well to read the lot of them. However, most software engineers would probably find his methodology too formal, as most programmers I know prefer a loose, casual working style. But there's no doubt that the SEI's methods are worthwhile when quality and reliability is important.
Also, before buying any technical book, check to see if the Associaton of C and C++ Users has reviewed it - try typing "management" into the search for their. (I'm afraid their book review server is down just now but I expect it will be back up soon.)
The ACCU makes a point of reviewing books that they suspect might be stinkers, so they can write reviews that warn you away from books that suck.
Request your free CD of my piano music.
Ive been a tech, then I was a manager for a long time, now I'm a geek again, by choice. I was a good and popular manager, with both my bosses, and especially my staff. I have managed teams of up to about 50 people.
Being a manager is about 1) getting things done, 2) with people, 3) more efficiently than if you weren't involved with the process, 4) in a way that is sustainable over the appropriate horizon, 5) as perceived by your superiors. Focus on those things, in about that order, and you'll be fine. There are a lot of ways to accomplish this. Sometimes #3 is best accomplished by you taking off and playing golf. Really. Don't make changes to the way things are done now lightly, and figure out who on your staff would appreciate being asked their opinion. Make sure that you also figure out whose opinion you should listen to. Realize that you team still wants to like you, but needs to respect you as being fair. Pick a moment to do something that is unpopular, but the right thing to do.
I suggest a book called Leader Effectiveness Training, available from amazon, and, if you are leading devs, Controlling Software Projects by Tom DeMarcos. A lot of his stuff is out of date, but a lot isn't.
Have fun. Being a manager means you get to try and focus a group to achieve something that is bigger than what you can do alone. That can be great fun.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
If, at heart, you love nothing more than to crank out code that is elegant, fast, small, and efficient, then you're making the wrong move.
If you like getting the job done and doing what is necessary to make that happen, you're making the right move.
Really, it's that simple.
Get yourself Michael Lopp's Managing Humans, or read his blog Rands in Repose.
This is a light but competent take on the human factors of sofware engineering. For the more formal approach, I recommend Scott Berkun's The Art of Project Management.
Between these two books and your experience, you should be golden. But it is also good to have a mentor. Approach the best manager you have had in your career as a tech and ask them to have a coffee with you once a month. They don't have to work for the same company, as you won't be discussing the strategic or technical side of work, but rather talking about the practical side of coordinanting people.
Congratulations on your new position (I somehow assume it is better paid), and good luck with your new challenges.
http://barrapunto.com/ - News for nerds, en español
The parent did not give the details of what size of company he works for, but often most HR departments will have several training programs that all managerial types will need to take. The programs can be extremely helpful, as they'll provide you with the company's perspective on things that may have seen mysterious or down-right strange when you were a worker-bee. Most of the training sessions will be presented in day to two-day seminar style formats. The advantage to you is, it's on the company's dime, especially if a smaller company can't afford tuition reimbursement.
YMMV
A good, no BS resource for the "softer side" of management is at http://fridayreflections.com/. The idea seems to be short stories on topics like accountability, results and learning ... with stories from actual management episodes. A wisdom download instead of a methods and tools download, if you will.
... but there is tons more.
My favorites: A desk is a dangerous place to view the world, many fail to grasp what is right in the palm of their hands
Take it from a coder that ended up in management because the guys ahead of him were fired and then ended up laying off his best friend; management sucks.
"Managing Management Time" - good book on the most frustrating part of management for techy types - organizational politics.
Truthfully, the best lessons I've had have been from my father, who was a construction foreman and a great parent, and my first couple of boss-mentors.
Listen to your people, be flexible, work harder than they do, protect them when you can, fight for their needs, manage expectations early, never over promise to your boss or your employee, guide your people when they get off track, be stern only when necessary, remember that you are just the head of the body that is your team, your company just keeps you around so that it can make money from your team's efforts, that you have a symbiotic relationship with the other managers around you. Watch out for negativity and nip it in the bud. If you have problem person, try hard to redirect them, but if you can't get through to them, cut them before they drag down the rest of your team. Never tolerate a prima donna; knock them off of their pedestal. Remember, some of the best people only get to be great after they screw up a few times. If you choose to forgive someone for something, that is the end of it; never speak of the incident again.
Management often requires an understanding of your business, so that you can focus your team on generating the most value to your organisation.
This is a big gap for a lot of technology people who are often focused on the nuts and bolts, but might understand (or be interested in) how their team fits into the organisation or what the business value of the technology they are creating is.
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.
Sounds kind of zennish, but learning to be a good manager means learning about yourself and how you best interact with people. In some ways it's useful to observe other managers and how they fare, but each person is different. For some people, something about them allows them to do that drill sargeant thing effectively. For others, the debate master tact is their natural flow. You get the idea. Find what works.
Also, find what doesn't work. Everyone has kinks in their personalities that sometimes needs to be sanded down a bit to fit into a managerial role. Or, those kinks can actually be a surprising asset. It's really a soft skill, unlike programming or data analysis.
That said, it's also good to know the ins and outs of hiring, firing, and HR policy. It's also helpful to keep reasonably organized and follow up with people proactively.
It can't be done. You don't have the people skills. Your autism will interfere.
... but. I found myself in exactly the same position not so long ago. I was a member of a medium-sized development team (25+ people) which had no management at all. The result was that various people from different parts of the organization were giving us tasks and nobody really knew who they reported to. Yes, it was a mess and I would often bitch and moan about it - I could afford that because I was on friendly terms with the top management.
Then one day something karmic happened: I was told I was becoming the manager of that team. As I didn't have a manager to look to for example, I had to learn somewhere else. So I went to Amazon and I bought every book on the subject which looked promising in the reviews. Here's my top 5 in order of preference:
1. Peopleware
2. Managing Humans
3. Joel on Software
4. The Art of Project Management
5. Up the Organization
Beware of number 5 - not everything applies to software development teams, but it's a good books nevertheless.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Ever heard the saying "people are promoted to the level of their own incompetence"?
Yes, and its not just a saying, its called the Peter Principle. And according to Wikipedia, the official quote is: "In a hierarchy every employee tends to rise to his level of incompetence." I would have to agree with original beware comment. I also feel this quote from the Wikipedia article is also meaningful in this context and provides some additional insight:
"The employee's incompetence is not necessarily exposed as a result of the higher-ranking position being more difficult -- simply, that job is different from the job in which the employee previously excelled, and thus requires different work skills, which the employee usually does not possess. For example, a factory worker's excellence in his job can earn him promotion to manager, at which point the skills that earned him his promotion no longer apply to his job."
No Lawyer here, but don't those kind of costs get worked out as counter suits for damages?
Money is the root of all evil?
The problems in management are often rubbery, mysterious misshapen things. The actions you take in response to these problems will reflect your unconscious and conscious assumptions about what your work is.
What Peter Drucker did during his life is crystalize some of these problems and find positions of strength and humanity that a manager can actually express at work.
Until another thinker appears, I would urge you to get every Drucker book you can from the library. Scan them and you will see the evolution of business thinking since WWII. Give at least one of the last of his books a good reading.
His studies of how to hire, how to fire and what counts in employee performance are still great. His recognition and exploration of the problem of performance in a non-profit organization is important.
I hope we will be fortunate enough to hear another management thinker of such scope.
I was a techie, now a senior manager. There are a number of free resources available at http://www.sans.edu/resources/leadershiplab No expertise claimed, as I didn't know what to do about something, I researched it and wrote it down. Maybe it will help. And the best piece of advice I was ever given, use outlook, every time you tell someone to do something copy the body of the message into the calendar and set a reminder, once you start managing over ten people you will be amazed how poor your short term memory gets. Good luck!
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.
- Give me the freedom to explore new/offbeat ideas, but remind be of the focus of my explorations. Personally, I'd explore just for the sake of exploring.
- Communicate. Hold occasional meetings to tell me what the company is up to, what the latest rumors are, and how my job fits in.
- Protect me from the many idiots who want to make the target a moving target. And don't tell me about how they're protecting me, or from whom. To constantly tell me how they're protecting me from getting jerked around by upper management is passive-aggressive bulls**t.
- Do not attempt in any way, shape, or form to micro-manage me. Ever.
- Don't overload me. Two to four "high priority" tasks are all I can handle. My manager's job is to set priorities, give me one or two "ASAP" tasks, a few "think about these in your spare time", and keep me from being overwhelmed. When priorities change, let's talk about it. I can tell you how close I am to finishing tasks and possible consequences of delay, but tell me why priorities are changing, and let me offer options. I want to finish these tasks too.
- Keep me focused, but not by checking up on me every hour. I am, like all the good coders I know are, partially ADD. Yea I get distracted, but when I'm focused baby, I've got megawatt laser beam concentration and I can go for a dozen hours without blinking. Yea, I'm gonna go read Slashdot one or twice a day - it's called taking a break. Deal with it.
- I'm a friggin' artist, OK? That means all that temperamental, "spoiled baby" right-brain stuff applies most of the time. But I do have to be a cold, dispassionate, analytical, SOB sometimes, particularly when evaluating my own code -- what can stay, what can go (remember ego-less programming?) All that ping-ponging stresses my corpus callosum.
- Treat me with dignity and respect, even though my office is a shambles that looks like a book store that exploded and I wear tee-shirts that are older than half the programmers that work here. Give me an on-the-job sabbatical every year or two where I can learn a new language (computer or human).
Caveat: I've been writing s/w since 1977.The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
I dunno. Lead developer/architect isn't so bad. Build the role the way you want it... more like the architect from Mythical Man Month... you are really still a developer, but you are able to depend on your team in order to add leverage your own abilities.
It is IMHO a mistake however to call that a "management" role. I don't think you can manage and be the architect at the same time. They are different jobs and you won't have time for both.
My personal acid test as to whether you are really a manager is if you have input on and are responsible for a budget.
Authority must come with accountability, and unless you have input to the budgeting and planning processes, you don't have sufficient authority to be an accountable manager.
-- John.
Check out this series of posts. They highlight many of the problems you are likely to see when making the transition. Becoming a Lead Learning to Trust Delegating We Not I
I was once taught about firearms: 1.) You never point a gun at anyone you don't intend to shoot. 2.) You never shoot anyone you don't intend to kill. From those two basic axioms you can derive all sorts of appropriate behaviors for the care and handling of firearms, in dangerous situations and otherwise.
... if I follow your advice, my boss will only ever hear my name when my employees screw up. When everything is going right, I won't even get a pat on the back!"
... and everybody in the room wants to vomit. You act like that and everybody can smell you from a block away.
I like those sort of truisms. So I have two about management, or more specifically, about leadership. I no longer remember whether someone told me these or whether I made them up myself. I think I may have just made them up. But they go like this:
1. If you're in charge of a project, and you have goals and a deadline, and everything goes wrong and the deadlines are blown and the goals are not met, ALWAYS ALWAYS take the blame yourself. "I told you guys we'd be done by this date. Well, it looks like I screwed up. We're not done."
2. If you're in charge of a project and everything always goes right, the goals are met and exceeded and everything happens before deadline, ALWAYS ALWAYS give the credit to your team. "Everybody on staff came together on this one and they pulled out all the stops. There were a lot of long weekends involved for this one and I can't praise the team enough."
If you can do those two things, consistently and without hesitation, I'll guarantee you'll be a more effective leader.
A weak leader will get scared. "Wait a minute
Bullshit. Senior management knows whose responsibility everything is. They put you there. If you screw up and you try to shift the blame somewhere else, they'll see that too, unless they're completely incompetent. If nothing else, your subordinates will see it, and they'll despise you for it. Nobody likes a manager who tries to climb the corporate ladder by standing on the backs of the rank and file. Your team will just get weaker and weaker.
I can't tell you how many times I've sat in on a small meeting and some criticisms came up about lost productivity or whatever, and the manager in charge responds with, "I know, I know, but no matter how many times I try to tell Julie what we need, she just never gets it right. She's been a real problem. I think I might have to put someone else on it"
As in so many other facets of life, it's all about respect. Give people a square deal day in and day out and they'll respect you. That respect is a kind of coinage, and it will let you make the difficult decisions when they come along -- say, if someone really and truly isn't working out.
Now that I think about it, I guess after all there's really only one axiom, and it's the Golden Rule.
Breakfast served all day!
One thing I've learnt in my long career is the more you are paid, the less you have to work. If you're getting a big rise as you move into this management position look forward to a large reduction in stress and more free time. If not, then turn it down. If you're technical, management in a technical environment is easy; nearly all your staff are highly trained and know what needs to be done, Just let them get on with it. Unfortunately most managers I've met are totally non-technical, and clearly delight in being so (the fools). They run around like headless chickens, i.e. you'll have your feet up most of the time and the work you have will mainly be preventing the 'headless chickens' screwing stuff up and upsetting key staff to the point they leave.
i.e. don't sweat it.
threadeds blog
I think you should find an existing manager who you trust and respect (preferably not now in line above you) and ask them to mentor you. You get to talk about problems and issues, and they advise you about how to tackle them. Most good employers will already have a mentoring and management training programme in place, so you should be able to do this easily. If not then push for it: you need it, and probably a lot of other people in your workplace need it too.
Failing that, make it plain to your immediate boss that you are learning on the job and will need lots of support, especially in the early days.
Good luck,
Paul.
You are lost in a twisty maze of little standards, all different.
I've found The Disney Way book very interesting to me (who want to know what happen in my work place). I don't know what others may think of it as I am not a manager or even a wannabe one atm :D.
You can lose your cutting-edge very quickly, I've discovered!
I was promoted upwards & sideways into a different team a couple of years ago, and I've had to swallow my pride a few times when either my current team members, or the people in my previous positions, demonstrate a better technical grasp of the system than me.
Managers can & should keep up an awareness of the latest issues/developments, but they shouldn't be expected to keep their practical skills to the same level as before. They have other duties now, which their team members prefer they spent their time on - like arguing their case to The Boss, making the policy decisions, writing the reports.
So there is some good and not so good advice here. Normal for /. b le-About-Business/dp/0787968056/ref=pd_bbs_sr_1/10 4-5599184-8599935?ie=UTF8&s=books&qid=1188370691&s r=8-1
e rship-Fable/dp/0787960756/ref=pd_bbs_sr_3/104-5599 184-8599935?ie=UTF8&s=books&qid=1188370818&sr=8-3
m petitors/dp/0787976385/ref=pd_bbs_sr_2/104-5599184 -8599935?ie=UTF8&s=books&qid=1188370818&sr=8-2
Anyway, a couple of good books I discovered which were helpful and haven't already been mentioned were by Patrick M. Lencioni:
http://www.amazon.com/Death-Meeting-Leadership-Fa
http://www.amazon.com/Five-Dysfunctions-Team-Lead
Here's one more that I haven't read:
http://www.amazon.com/Silos-Politics-Turf-Wars-Co
These are easy reads which have some really good points regarding how to run meetings and lead a team. Good luck.
Who the hell are you -- Jay Leno?
I think the rest of us are bright enough to get the point without you coming by to drive the lesson home, just as Jay has to do -- repeatedly -- after each (alleged) joke in his monologue. Some night, the audience ought to rear up en masse and scream, "Fucking stop the shit, Jay -- we're all bright enough to get the joke (if any) upon delivery. You don't have to act it out five times for us."
"Asshole."
I'm not the OP but here's a question and a statement.
"Don't speak for the rest of us"
And when slashdot says "government is this", "business is that","consultants are","Certificates will","managers are" or even "people are idiots". Aren't they guilty of the same thing you're accusing the AC of?
Nope. First, "slashdot" doesn't say anything. Individuals do. Second, saying "people are idiots" is not equivalent to saying "nobody thinks people are smart." The first is an expression of an individual opinion. The second purports to speak for others.
"particularly when you don't have the minimal courage required to associate your whining comment with a Slashdot handle. "
Many of the comments mentioned were done under a handle. So much for a sign of quality.
Who said anything about quality? Not being willing to put your handle on a comment doesn't have to do with quality. It has to do with standing behind what you say, even if you're only standing behind a pseudonym.
Read the EFF's Fair Use FAQ
Those mounted between your ears.
There are two simple rules good managers remember:-
Look after your staff, so that they in turn feel motivated to look after you.
Do the decent thing for everybody, i.e. "Do no evil".
You'll need information to base your decisions on so you'll need to gather that information.
Ask how projects are doing, ask how people are doing, aks if they see signals that things are going right or wrong.
If they don't tell you when things are going wrong, you won't know until it's too late and it's your job to do something about it before it's too late. So if things go wrong, don't start to blame, but start to solve.
You're depending on the developers, so you'll need them to trust you.
Privacy is terrorism.
and use them whenever possible...
Synergy
Strategic Fit
Gap Analysis
Best Practice
Bottom Line
Value-Added
Proactive
Win-Win
Blue Sky Thinking
Think Outside The Box
Fast Track
Result-Driven
Empowerment
Knowledge Base
Total Quality
Quality Driven
Mindset
Client Focus
Leverage
Thoughtshower
Bleeding Edge
Team Player
----------------------------------- My Other Sig Is Hilarious -----------------------------------
I did this transition about 10 years ago, after a few years as a developer. I was working at one of the 2-3 largest software companies in the world, and I managed to succeed more as a manager than as a developer.
I read a whole slew of books, but only one really stood out: "First, Break All the Rules". It's a fascinating book based on Gallup research of managers who are successful across all different sorts of fields. Many of the points it makes are counter-intuitive, but they've worked quite well for me in practice. Don't miss this one.
Other than that: 1) Keep up with your technology area. You need to be able to make judgment calls and have your employees respect them. If you're still coding, this probably isn't a big problem. 2) Know the strengths and weaknesses of all your employees. A manager is 50% psychologist, frankly. 3) Be confident and decisive, but admit your mistakes.
I'm in the transition phase from sysadmin to manager, and the most help I've had came from Dogbert's Top Secret Management Handbook.
On a more serious note, there seem to be three main sorts of manager, at least initially:
1. Doesn't change a thing, goes with the flow. This works fine as long as what you're inheriting people and procedures which work OK and don't really need your help - but doesn't do anyone any good if you hit issues.
2. Makes radical changes without stopping to think of the potential impact of them. Things like deciding "Let's cancel the staff christmas party" some time around the end of November. Yes, it gets you known as someone who's not afraid to make decisions. It also gets you known as a thoughtless moron who cares not one whit for his staff if he can save a little cash - which is an extremely good way to guarantee that the feeling is reciprocated by your staff. Realistically, unless your company or team is in real trouble the "radical changes" bit shouldn't be necessary - and even if they are, "failure to think about what you're doing" is still a bad move.
3. Looks at what's currently happening, tries to engage brain and see what could be improved while leaving well alone if all is well.
I've tried to follow 3.
One other piece of advice: Learn to delegate. It's hard initially but at the end of the day, there's no point managing a team if you're going to try and do all the work yourself. Make sure you know all the strengths and weaknesses of the people who work for you, and delegate work to them accordingly.
I'm not kidding when I say it - watch The Office, and maybe Office Space.
Then think what you wanted from your manager. Listen to your "subjects" and don't discard what they have to say. Always have an understandable reason for what you're doing/saying. "It's just the way it is" is not something employees accept.
Reading all those "how to become a manager in 48 hours" and "managing for dummies" books won't give you shite. It all comes down to experience!
This is blinging
If I see another ask slashdot about changing to another career, moving up to management, or how to get started in field x/is my degree worthless/is it worth it to get a degree I may projectile vomit repeatedly.
I don't know, I've been seeing these same stupid more or less identical questions posted to the front pages for years, this time something just snapped. If I see any more of these dupe ask slashdots I swear by all that is holy that I will violently attack a flock of paper swans!
It's critically important that a manager establishes a culture and expectations. These expectations must be fair, they must be clear, they must be consistently applied in hiring, work assignments, resource planning, firing, transferring, and performance evaluation decisions and be exemplified by the manager's own actions on a day-to-day, minute-by-minute basis. The level of flexibility an individual manager has in this regard is of course related to their level (counted from the TOP, not from the BOTTOM, of the org chart!) - but if you can't do what is right, reject the position and keep coding - far too many technical people who SHOULDN'T become managers do, and it's painful for all around them.
/. -- you won't have time anymore!
It's a manager's job to not only insulate, but to stand up (to their manager, their manager's manager, the CEO etc) when, for example, it's important to keep from launching on an impossible task. An effective development manager must always put their team before themselves. An effective manager must be willing to sacrifice their own job and career if the alternative is to sacrifice the team (it turns out, if done responsibly, rarely does one have to actually sacrifice their job - although their career path is a completely different question).
Rarely will you go wrong by your team if you first ask "will my team members follow me to another company because they respect, although not always agree with, me" before asking "what is the impact of this on MY career/job".
Also, a first level manager must always remember that everyone is unique. In reality, you're not going to make big changes in the behavior of senior developers -- either figure out how to exploit their strengths or help advance their career with a transfer or dismissal if they are never going to be happy working for you. Also, mentor the heck out of junior developers -- that's part of your job and your responsibility and they should appreciate it.
Help your people from getting into trouble... Increase their estimates if they are notoriously optimistic, add time for additional desk checking/code review if they are quick but a bit sloppy, step between them and YOUR management without hesitation to keep them out of a nasty situation.
A manager must embrace and USE the process (until they are successful at getting the stupid parts of the process eliminated if necessary). It's there, it's sometimes in your way -- so you might as well exploit it -- if a Senior PHB wants grossly detailed breakdowns of estimates to justify your rollups, start tossing in the time for every little thing so the schedule only swells - that will usually shut upper management up.
Put everything you communicate (especially upwards) in writing and review this stream periodically to both understand yourself better and to use as future ammunition if needed. If you reach a verbal agreement, follow up with an email -- such as: "To recap what we discussed earlier today, it's my understanding that the performance of function X in standby mode is unimportant so our team will not spend time on performance analysis of X in standby mode. Please let me know if this decision changes in the future.".
Although a component of the job is technical, your FIRST job is as a manager.
Oh, and stop reading
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
http://www.amazon.com/Behind-Closed-Doors-Manageme nt-Programmers/dp/0976694026/ref=pd_bbs_sr_1/103-7 947205-1114222?ie=UTF8&s=books&qid=1188376543&sr=8 -1 I found this book invaluable. It covers everything you need to manage people in a way that's easy to understand.
Just do what you always did, but before you sit down and spend 72 hour jolt-cola coding sessions coding it yourself, have a project meeting to discuss it, and see if you can get your team to do it for you.
You will have many pressures on your time - Getting Things Done by David Allen offers a practical methodology for processing work effectively. You need to understand how many things you can effectively do at once, for most people it's one, but for many it's two or more. Do this many and no more. Allow time to move from one task to another, to get rid of the "old" task and prepare yourself for the "new" task. Understand your "work unit". This is the amount of time you can spend on a task working at maximum efficiency. For me, it's 25-30 minutes, for others it's an hour, or "until the job's done". Everyone is different. Organise your time into these units. If you have a "work unit" of one hour and an eight hour task, spread the task over eight individual hours if you can, alternating with other tasks. If you can't, recognise that you're going to be somewhat more stressed working out of this pattern. You need to be ready to forgive yourself for not achieving everything you want - there is an inexhaustable hopper of work others want you to do, let alone the things you want to do yourself. You are one person, and you have x work units a day and you can do y things at once. That's your total capacity. Then, learn to delegate effectively. I.e. expecting the person doing the task to do it differently than you would, probably slower and with less motivation.
Get used and feel comfortable dressing suit and be comfortable dealing with and influencing people. This are the things I would add to your profile.
VirtualWorldsHub.com - News, forums, resources
...that may be paraphrased from wherever I nicked it from, but worth a look:
1. Know yourself and seek self improvement.
2. Be technically and tactically proficient.
3. Seek responsibility for your actions.
4. Make sound and timely decisions.
5. Set the example.
6. Know your troops and look out for their welfare.
7. Keep your troops informed.
8. Develop a sense of responsibility in your subordinates.
9. Ensure the task is understood, supervised, and accomplished.
10. Train your troops as a team.
11. Employ your command in accordance with its capabilities.
One of the best Discussion Threads recently!
But having made the same transition myself the most useful things I've found are:
1) Software Project Survival Guide by Steven C. McConnell
2) The Mythical Man Month by Frederick P. Brooks
If you've not read both of these yet be sure to do so.
owes me a new monitor to replace the coffee covered one sitting in front of me.
I would highly recommend "Herding Cats: A Primer for Programmers Who Lead Programmers" by J. Hank Rainwater.
Much of what the previous posters have said about management is useful and true - especially the HR side of things. But that is 'just' nuts-and-bolts (not saying 'easy'). Leading is help establish where the company/division is going - Managing is making sure you get where you are heading (no matter who sets the goals). And leading from below is hard - think of a tiny auxiliary rudder on a big ship - but can be done, slowly. But it has the greatest reward.
What IT or business policies would help your company? Who should implement them? How do you get this across to everyone in all departments? (This is where the Win Friends and Influence People book comes in).
Stand up for your people, but also stand up to your people - ask for commitments from them in writing, and use it to evaluate their work. Transparency in expectations is usually welcome.
The quickest way of getting the team on your side is to try to eliminate un-needed work and other pain points that get in the way of what they do best. If you have developers working in Excel, PowerPoint, MS Project all day they aren't doing what they were hired to do.
==========
The Manager's Cheat Sheet: 101 Common-Sense Rules for Leaders
Inside CRM Editors (
http://www.insidecrm.com/features/Manager-Common-S ense-Rules-082207/
Management is all about connecting with the people on your team. So how do you effectively manage a team? With common knowledge, of course. These are a few back-to-basics rules that will help you develop management skills that really matter.
Body Language
Like it or not, your body speaks volumes, even when you are silent. Here's how to express an attitude that's appropriate for a leader.
1. Stand tall. Keeping your shoulders back and holding yourself up to your full height will give you an air of confidence.
2. Take your hands out of your pockets. Putting your hands in your pockets is often seen as a sign that you have something to hide.
3. Stand with your arms crossed behind your back. This will help you adjust your posture, and it leaves your hands in a position that is open and not intimidating.
4. Make eye contact. Always look directly into the eyes of the people you are speaking with. This shows you're interested and also gives you a sense of confidence.
5. Sit up straight. Even if you're at an 8 a.m.meeting and feeling tired, it's important to sit up straight in your chair. Slouching makes you look disinterested and can give off an unwanted air of laziness.
6. Face the person you're talking to. This shows you are interested and engaged in the conversation.
7. Shake hands firmly. For many, a handshake is a reflection of the person you're shaking hands with. You don't want to come across as unsure or overbearing, so make sure yours is professional and confident.
8. Always smile. Smiles are contagious and will make others feel positive when you're around.
9. Look your best. You don't have to be model perfect every day, but you should dress appropriately and neatly. Clothes can have a big impact on the way you're perceived.
10. Walk confidently. Keep your head up and take even strides.
Meeting Deadlines
No one will be happy if your team has to rush around at the last minute to complete a project. Follow these tips to make deadlines less stressful for everyone.
11. Only promise what you can realistically deliver. Don't create deadlines that you know you can't meet. By only promising what you know you can do, you'll be able to finish on time.
12. Set clear goals. Once you know what you need to accomplish, it helps to know how and when you want to do it. Put your goals down on paper and make sure everyone on your team gets a copy.
13. Organize a team. Many of your employees will have unique strengths and training that can make them great assets to certain projects. Pick a team that has the right skills to carry out the job.
14. Delegate t
The "it's only in RAM" defense was used because, from what I understand, the judge can't legally compel them to produce new data. The argument was that since the IP addresses were only in RAM, creating logs would be creating new data. The judge basically said that if the IP addresses are in RAM, it's not new data and the logs were just a record of data that already exists (however fleetingly). Sure, it's trivial to log the connections--well, perhaps not in performance or disk space, but from a technical standpoint it is. That's not really the point though. The data isn't stored in RAM like they would be in logs. Periodic snapshots of RAM wouldn't be new data. Logging the IP addresses is creating new data (IMHO).
ehm well dont worry, i got that strange feeling that a lot of managers are not realy educated too. /laptop... woehahaha
In fact more often their technical skills are below average, they are often highschool drop outs.
And yes they steel more money from a company then the average worker.
By using office things for personal usage "hey thats a nice symbian / pda
The only magic is managers (believe) that they have some idea of cost and profit control of their team.
Alltough most of times they are not informed by real figures, or long term goals of a company.
Small managers are far more often just the working dogs for the higher management, doing the ugly work.
But be sure to always say yes to those guys above you, as you're only allowed to argue with people below you.
If you're attached to the people's work around you, you will be probaply a poor but nice manager.
Realy i like these kind of human mangagers (i've had a lot of types).
If you just dont care about their work but see another more profit chanche at some other division, and you just follow your money track. Then you're not nice, but life is perhaps more simple, alway abend failing tasks soon. Dont feel your need to be in touch with that blame others. Only go for the winning goals of your company. And you will soon climb up the monkey tree. (yeah a tree because you know the shit always falls down the tree).
Hm i would recomend to read a lot of dilbert stuff.
So you will oversee a lot of these days strategies, overseeing things is a good way of understanding it as whole.
And altough you might think you are important always keep in mind, when you become less technical you're no longer something that brings money in, but become something that cost money for a company. So be sure people dont see you as a waste of money.
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
Is that you? who else left mmmppph mmppphh mpphhital?
--jdp Maintainer of VisEmacs
Everyone knows that just because you're a good technical person, it doesn't mean you're a good manager. So don't turn in to that guy that everyone hates. Be honest with yourself ... in a years time, look at how you manage things, look at the happiness of your employees, of yourself, look at the amount of work going on is right, and try and think of how happy you'd be if you were being managed by you. And, if the results of that aren't as positive as they should be, do the right thing and step aside. There is no lost face here - not everyone is made to be a manager, plain and simple. But by continuing when you're not suitable for the job, you're impacting other lives, potentially very negatively, as well as probably impacting your own life and happiness.
Thats my suggestion - just be honest with yourself about your performance, and, if things aren't good, find a way out.
Best of luck!
We emerge from our mother's womb an unformatted diskette; our culture formats us. - Douglas Coupland
define what is expected of you IN DETAIL. Ask any ten folks what a manager does and you'll get ten different answers.
I've had lots of managers that wanted to write code. That's not their job any longer and they made doing mine harder.
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
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
For what it's worth I've posted my personal list of top-ten software management tips on my blog: http://ericomguy.blogspot.com/2007/07/top-ten-list -of-tips-and-suggestions_31.html/
This list is based on my own personal experiance, and would have certianly helped me when I got started as a manager.
Hopefully it can help you as well.
-- Dan
Those managers are typically the ones that did not suffer repeated head trauma.
Problem is you always end up at one point or another with a manager that you are certain has so much head trauma that they gave him the job out of pity. Or to punish you.
Good managers are gold, problem is good managers typically leave as they get better gigs. bad managers stay ther forever until a company is full of the bad managers that cant make a decision to save their life.
First off, holy google batman, I was thinking about posting this same thing to /. this morning. I made the transition from architect to manager about 8 months ago and it has been horrible. Due to corporate BS, while I took over for my old manager, my position was never filled. I was told it would be filled later on. After 4 months of getting completely buried trying to be the manager and the architect, my company so graciously hired a senior level programmer. And then to top it all off, the lead on my team decided that she didn't like development anymore and went back to school to do finance. Where does that leave me? With a team that is in 1 person short and no one on the team can make a technical decision for themselves. My good weeks are 60 hours, but I have had weeks that are over 80 hours.
Enough whining though, right? My point is, do not make that transition unless you have the proper resources in place to offset some of your responsibilities. Otherwise you are going to be doing 2 jobs with a high amount of context switches.
The judge didn't want the sticks of RAM in a static-free bag. She wanted the information from that RAM -- the tables and other data stored therein -- printed out in a nice, readable, understandable manner, and given to her.
The torrent tracker guys said the infomation she needed was in RAM, not on the HD, and that's why she couldn't have the data they in fact did have. She patiently explained to them that if they had the data, no matter HOW it was stored, it was relevant to the suit and needed to be handed over.
What's so hard to understand about that? If I were a judge, and a defendant was trying to weasel out of giving me info they had just because it wasn't on a hard drive, I'd tell them to take it out of the g'dam RAM and hand it over.
It would certainly help if you had your MBA. A lot of the gripes I see on this thread are misplaced, angry retorts by hardcore developers who have no idea what the difference between leadership and management is; they're only victims of it. I've been a developer for about as long as you have. I've grown tremendously as a developer, but the last few years I've realized I'm ready to do other things. I want to do other things at a higher level. I returned to school and got my MBA, and also passed the CMBA exam. It was definitely worth it; you understand the other side of the coin, the big picture. It explained so very much to me. If school isn't an option for you, I can recommend two decent books:
Herding Cats: A Primer for Programmers Who Lead Programmers
http://www.amazon.com/Herding-Cats-Primer-Programm ers-Lead/dp/1590590171
The Ten-Day MBA 3rd Ed.: A Step-By-Step Guide To Mastering The Skills Taught In America's Top Business Schools /0060799072/ref=pd_bbs_sr_1/105-0787190-8957248?ie =UTF8&s=books&qid=1188391102&sr=1-1
http://www.amazon.com/Ten-Day-MBA-3rd-Step-Step/dp
These books won't give you management experience, but they will get your feet wet in a proper way. Also, here is a helpful list, from one developer who transitioned to management to another (I don't remember where I got this list, but I've kept a copy of it ever since):
Ten Signs of an Incompetent Leader
Poor leadership surrounds us, it's a fact of life and they seemingly find a way to keep their jobs. They are more focused on their personal needs and not of the professional needs of those below them. They have a hard time developing their employees because they lack the proper management techniques to do so. A leader is someone who you would follow to a place you would not go alone. Leadership is about action not status.
However, the question is, how do we know when we are dealing with these flaw-ridden individuals? A lot of the time, a poor manager can make the perception that he/she is busy and organized. I have developed a small guideline that can help pinpoint these leaders.
I know, you asked not for books, but I suggest anyway this one: http://www.scottberkun.com/the-book-the-art-of-pro ject-management/
It is by Scott Berkun, a former Microsoft team leader. It is well written, and organized in short chapters easy to absorb. It helped me a lot in a similar situation.
Well, you're using the word "transition" as a verb rather than a noun, so you've plainly go the hang of Suitspeak already. Boost your buzzword vocabulary a bit more and you'll go far. Remember that the trick is to sound cool and keep the information/talk ratio low...
http://blog.assembleron.com/2007/07/11/what-motiva tes-programmers/
I highly recommend reading the book 7 habits of highly effective people"
From Engineer to Manager: Mastering the Transition
by B. Michael Aucion
ISBN-10: 1580530044
5/5 starts on Amazon.
I'm currently reading this book. The price is a little higher than some might be willing to spend, but I think the book is worth it. The target reader is an engineer about to make the transition into a managerial role. Lots of good references to additional material.
I think it's exactly what you're looking for.
I've found Colin Powell's Leadership Primer Helpful. Management is one thing. Leadership is far more valuable a commodity. You should be able to find it in google, I believe it's in the public domain.
- The Mythical Man Month, by Fred Brooks. A must-read for anyone doing anything related to software engineering at any level. Amazing to me how applicable it still is.
- Orbiting the Giant Hairball, by Gordon MacKenzie. Offbeat and easy to read. Has some good insight about navigating corporate life.
- Software Project Survival Guide, by Steve McConnell. Lots of concrete advice about techniques and tools for managing software projects. From what I've heard, there's some overlap between his books, so another one of his might be a better fit for your situation.
As usual, YMMV. Void where prohibited.All right. I'm an anonymous coward! So be it.
I realize that there are already 3,435 responses to the initial post, but add mine to the list. I too am in the position of manager when I should not be. False modesty aside, I questioned whether or not I should take on a management role from the beginning. I know myself pretty well -- well enough to know that I too ought not to be in management. I too will be resigning my position soon.
To the author of the original post, I offer this: know thyself. (The very fact that you wrote your original post seems to indicate that you already do!) There are some terrific thoughts in this thread. I agree with them, ergo "terrific", right?
- determine if you will be "managing people's time" only, or will have HR-type supervisory duties (paperwork, policy crafting, reviews, position descriptions, etc), or
- In the spirit of "you work for your people, as much as they work for you", good managers ought to try to "clear the path" for their folks to get their jobs done.
- give clear guidance. Do not manage by riddle (think master Po on "Kung Fu")
- criticize in private,
- praise when warranted
I could go on... but who the heck am I anyway?
As for resources, I found the one-day seminar by Lifeskills called "Excelling as a First-time Manager" to be a good use of $199.
my favourite managers:
* Ask what they can do for me.
* When I tell them about a problem they take it seriously
* They don't change the direction of my work after a 5 minute unannounced meeting
* They allocate time in my day for me to make structural improvement I think are important/fun.
Generally, they treat me like I am the boss, and part of there day consists of finding me resource so I can do what I need to do.
--meh--
There's two kinds of managers, those who look out for the interests of the people they're managing, and those who look out for the interests of the people they're working for. 90% of the time, those interests may be identical, but at some point, you're probably going to have to decide whether it's more important to "protect" your crew, or "enforce" company policy. I think a lot of the best managers end up never getting promoted again because of that.
who let a poet in here?
After transitioning to management, I found the best thing I have done is continue my education. A lot of the stuff you learn in business school you can learn by reading, but much of it has to be learned through the class projects you end up doing. In addition, you will end up reading a lot more books on management by going to school then you will likely do on your own.
In God we trust, all others require data.
There is one resource above all which will help in your trek towards management:
Children.
The more the merrier, but with each acquisition there is an inverse ratio of experience to leftover energy for your own agenda.
Good luck!
Pass the BS down the chain
"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)
People often confuse that being a manager is like making all the important decisions.
My understanding is that manager is an HR role. Managers need to deal with performance appraisals, conflict resolutions, hiring and firing. Managers need to retain and motivate their staff often with very limited resources. At the same time managers need to allocate enough relevant work load to the team and justify the existence to the upper management why the team should be paid salaries in the first place.
All those things that architects and code monkeys never have to think about. I assume that HR will provide you some training since there are some legal consequences to the company if the manager does not handle and escalate certain types of disputes correctly.
Good luck!
A new resume and a good headhunter :)
Great resource of exactly what to do as a manager. http://www.manager-tools.com/ They have great podcasts that really get to the heart of what managers need to do.
Why are you asking this pack of bit-flippers about management? as you can see from the comments so far, the vast majority of slashdotters don't know jack about management, nor do they want to. My experience on the dark side was brief enough (about 2 years manageing 25 top-notch developers) that I was able to return to the light. If you like to get things done personally, avoid management.
;-)
read the One Minute Manager, and Monkey Management, listen to your people, and remember all the things you hated about the bad managers you have had, and you'll be fine.
try to keep your skills current if you can, or at least don't assume that nothing has changed/improved since you were a hot coder N years ago
No, in a two-stroke engine, the oil and the fuel are one. They're mixed together, swirl around the crankcase together, and are combusted together.
If you took the "oil" out, the engine wouldn't run at all.
O lord, bless this thy holy hand grenade, that with it thou mayest blow thine enemies to tiny bits, in thy mercy.
First, I wouldn't say it is a transition so much as a career change. Like becoming a Baker when all you have done for your life is dig ditches. Second, I will say you need to figure out where the heck you have landed. It isn't Kansas anymore. You are now in the world of Harvard and Yale MBA's, and no matter what you achieve for your firm such people will forever hold you in contempt since you don't wear their school tie. Third, You need to figure out where the heck you are going with this. Do you have another step in your career path? Two? None? The last is the most likely. Techies who migrate into management are usually stalled at a manager-of-teams role within IT. Permanently. Unless of course you are headed down an MBA or PHD management path. Honestly. Senior people will never take you seriously without an MBA or PHD in a Management curriculum. They will take your credit for successes - they just will hold the belief that you lucked out, you got it easy, it was handed to you, or that the major blockbuster accomplishments you have done (if you are that good) were just not really that tough from a Management skill level perspective. Not fair. Not accurate. But very true - if you aren't a lawyer the lawyers will give you little respect in areas touching on lawyering (POs, Contracts, SOO, SOWs, contract terms), same goes for Accountants but it goes 10x for senior managers. You aren't in their golf game, much less in their Golf Club. Thats right. You have landed in the world where playing Golf is as important, or more important, than any other single management skill. Your most important decision this year may well be which Golf Club or Country Club to join (assuming you are not already a member somewhere). You do know how to tell if someone can really play Golf well, don't you? Hand them a six iron and ask them to play the entire course with the one club. If they play the game well, they need nothing else to still be competitive. If they use clubs as crutches they will fail miserably when the crutches are taken away. So, the real questions I have for you here is this - Do You Own A Six Iron? Have Fun! SFearless
I have made the transition from knowledge/skill worker to management, and the most useful management books I have found are Marcus Buckingham's. Start here:
r ently/dp/0684852861/ref=pd_sim_b_title/102-8240354 -6750512
http://www.amazon.com/First-Break-All-Rules-Diffe
In my experience, most management gurus suffer from one or both of the following: their experience is limited to a given field or company, and therefore not replicable elsewhere, or their success is due to personal characteristics not obtainable by others. Another problem is anecdote-based books... nothing against anecdotes, but I like something a little more rigorous.
Buckingham's work is solidly research-based, abstracting general principles expressed by the managers with the best-performing employees who were also rated very highly by the employees themselves. My organization has had great success (as reflected in employee retention and satisfaction) by using his performance planning approach.
The main thing to remember, though, is just that management is about working with people. Technical skills will help you work with technical people, but people skills are absolutely essential. Tact, diplomacy, insight, empathy, and firm and unflinchingly honest support of the people you manage will see you in good stead. Finally, a deep understanding of the principles (ethical, financial, legal) of your business will give you the foundation to make sound decisions without undue effort. Good luck!
Corruptissima re publica plurimae leges.
Read 7 Habits of Highly Effective People, take a course on personality types (Myers Briggs) to hammer home the point that 'projecting' your own reactions won't work well because different people think differently, then resign and use your new 'Architect' resume to get a high paying job somewhere that will let you code.
Seriously. Coding skills don't translate into the management sphere, so promotion = Peter Principle (or Dilbert Principle, choose your favorite) = welcome to your level of incompetence. Why stay there?
is competition good, or is duplication of effort bad?
In my old company, they had a saying: When you move from engineering to sales, you lose your mind, and when you move from sales to marketing, you sell your soul.
More seriously, if you want to go into technical management, bully for you! You can likely get a higher salary, but it may come with some costs in other areas. For instance, you may be more expendable in a time of down-sizing, or you may end up like my old boss. He loved engineering and was good at what he did, and he warned me that if I preferred designing and building things to pushing paper and attending meetings, then I should be careful how much managerial responsibility I accept. He seemed to regret that he was no longer doing any hands-on engineering, but that change had come upon him slowly, like the frog in pot of boiling water. Similarly, I met an older fellow who had everyone's respect but who occupied a "senior designer" type role only because he had tactfully declined promotions out of design and into management.
Consider this a conscious fight against the Peter Principle.
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.
I have a dual BA in Comp Sci and Management (Bus Admin). I have been in enough management positions to know that, although I've been told I'm good at it, I prefer not to do it. My take on it is this: you can't teach someone to be a manager. You either have it, or you don't. And, I think that you don't, or you wouldn't have asked in the first place. But feel free to try to prove me wrong.
The job of the manager is to provide leadership. On a day to day basis it means three things:
1. Being decisive. This isn't just making decisions, it is both being able to make hard decisions appear easy and giving the appearance of being confident that those decisions are correct. It is entirely about perception. You can have doubts, but in most cases, you need to keep those to yourself so that the decision will be enacted effectivley (if you doubt, then others will doubt, and you will make less progress).
2. Playing politics. Once you get off the lines and out of direct technical work, politics becomes a major factor, both within the company and without (vendor relationships, etc). (Aside: this is what you're supposed to "get" out of the Organizational Behavior classes). All human endeavors are inherently political, so beware anyone that tells you that "there are no politics here" or that politics aren't part of the job. As an architect, one thing you will find is that you'll need to be able to work well with the development managers (the ones who own the code) in order to accomplish your goals.
3. The Golden Rule. "He who has the gold, makes the rules." Well, that, and the other one, "Do unto others as you would have them do unto you.". If you keep this in mind in your dealings with your employees, you will do ok. It's the PHB's that forget that their employees are people that tend to be the ones that are ineffective and disliked. You won't be able to be their friend all the time - in the business world, sh** happens - but do try to make a conscious effort to treat your people like people and not cogs.
I've gone through this in the past year or two. It's been a bumpy ride, and I can't say it's been easy on me or my direct reports. However, I have found some success with the following:
1. Let go of development. Do it at home if you have to... if you're like me, it's in your blood. I've been writing code since I was 11, so I can't give up a 25 year old habit that quickly. But you need to let go of it at work -- that's not what you're there to do any longer. If you dive back into code, you're not seeing the forest for the trees. And you'll probably piss the developers off.
2. Change your appearance and mannerisms. As a developer, your clothes, body language, and manner of speech didn't matter so much. Now it matters a lot. Take a look around at leaders that you admire and use them as a template. This is not to detract from your personality, it's to enhance your credibility and change other's perception of you. If you get stuck in the "developer" mold you won't be successful.
3. Find a mentor that is at your level or above. Pick someone that is successful in going the direction you want to go in and one that you trust. Use him or her as a sounding board.
4. Stay close to your direct reports and buddies that are still developing. Not only will they give you honest feedback and perspective but they will give you intel at the ground level. These relationships must not be lost.
5. Talk to each and every one of your direct reports every day. Visit their desk for 5 minutes in the morning. Don't start off with work discussions, talk about their life. Let them know you think of them as people. Work issues will then be naturally forthcoming and honest and you need to know if there are things in their personal life affecting their work. An example from my own experience... one of my new direct reports was a junior developer. He was very eager for the first week or two under me, but then his productivity, interest, and quality rapidly dropped off. Turns out he was going through a bad break-up. A couple of weeks later everything came back work-wise with an added bonus: he really appreciated that I cut him some slack while he was going through a rough ride and told me that he owes me one. This came in handy a couple of months later when I needed an OT volunteer.
6. Don't be afraid to kick some ass. You've been in the trenches, you know who the slackers and poor leaders are. You now have some influence to change things, and this is probably part of the reason for your promotion. You know what needs to be done, so do it already.
7. Get yourself a productivity system. You're about to be inundated with email, meeting requests, and reports. I like Bill Jensen's "Simplicity Survival Handbook" but there are many others that will suit your personality. Just find one.
8. Have fun. It's still just a job.
"You disturb me to the point of insanity. There. I am insane now." - The Sprockets
Carefully observe (or recall) and analyze the actions and inactions, things done right, and mistakes of managers around you. Observe and analyze how your actions/inactions affect others (underlings AND overlings). Nobody can tell you how to become the manager you can be, they can only tell you how others did it. While this is useful information, it has limited applicability to you and your particular department. Read, sure, books by Fred Brooks, Drucker, etc., but avoid books by people like Jack Welch. Remember, most problems with employees (certainly not all) originate with, or at least can be mitigated by, management. Lastly, use the so-called 80/20 rule!
Seriously. Find a mentor, either within or without of the company you work for, who is in a senior managerial position and look to them for counsel and support. I was/am in a similar position with a promotion a few months ago, but the problem is that I hate the way my own boss works. I'd rather do things the way I feel they should be done, to achieve the same result. I mean, there's more to delegation that dumping work on someone and "let them figure it out" attitudes.
Find out what management training courses are available within the company as well, or find out if they'll subsidize courses from outside. If not, don't take the job! The only thing working for an untrained manager is being one.
It doesn't mean much now, it's built for the future.
not sure of your situation but you will need some basic accounting and budgeting background. also good to know how to read income statement and balance sheet.
A hand up and a foot on every chest...
I would do some reading -
The Software Survival Guide by Steve McVonnell already mentioned several times. You might also try Code Complete but that's longer and you just need the pointy head boss version now.
Also do some reading on software methadologies - I reccomend checking out
Crystal clear http://www.agilekiwi.com/crystal_clear.htm or Scrum or Extreme Programing, even the old waterfall method. You don't have to drink the cool aid but comparing the different methodologies will hilight the challenges of your new position and getting you asking the right questions.
I especially like how Crystal Clear distills down the objectives (but don't necessarily like how they manage them).
Your main challenges are:
Managing Change in the Project - it's going to happen, do it gracefully with the least developer thrashing (context switching)
Protecting your Developers from Internal and External Distractions
Increasing communication amoung your team and between your team and users. - A lot of developers are very introverted and you need to coax them to help each other out and get them to communicate with users, business experts to make sure they are coding things the right way.
Representing your project to the rest of your organization. - Huge issue which involves estimates, timelines, progress reports, feature/functionality issues, selling the benefits of the project, etc. Play the politics/personalities well enough so the developers can ship something good. Unfortunatly this depends on your organization
Anyway read the books not slashdot as I'm pretty shure I just missed something major. you also need deep understanding as to what is important for your company and how the higher ups see things.
As bad is being put in a management role, with the responsibility to deliver, and not being given the authority to fire.
I found myself in that situation: looking at a deliverable from a contractor firm that was far, far below standard, saying, I need to pull this, and being told, by one of my peers who was overseeing another part of the project being done by the same contractor firm, and by our manager that I couldn't, it would upset them, compromise the upstream work.
After 6 months of spelling out our requirements repeatedly and exhaustive detail, doing the contractors' QC for them, and taking criticism for the poor product, I finally insisted that it be pulled, by which time the upstream work was done and the resistance was removed. The reason I let it go so long, I'm afraid, was lack of confidence that this wasn't in some way my fault - which if I'd had the experience then I do now, I'd have known it wasn't.
The original decision had been made without any consultation with the people, like myself, who actually KNEW what that part of the project entailed.
Subsequently, I was told I could make a resourcing decision that was then, because of politics, overruled.
Something in the posters post suggests that this is not exactly a planned transition, on the part of the company or themselves. Nor was mine - I was backed into it because the company was resource-strapped. So as advice I'd say, make sure you have the authority to go with the responsibility.
From just a couple of days ago;S ense-Rules-082207/
r actice-OReilly/dp/0596007868/ref=pd_bbs_sr_1/102-8 644951-0733743?ie=UTF8&s=books&qid=1188403226&sr=8 -1
http://www.insidecrm.com/features/Manager-Common-
Also, I'd recommend the book:
http://www.amazon.com/Project-Management-Theory-P
The Art of Project Management (by Scott Berkun).
I've worked for too many managers who just have no freaking clue how to properly put together a schedule for a project - and every single time, you see the examples and rules documented in THIS BOOK, violated, and you end up with a disaster.
Workers who are not permitted to succeed, are unhappy workers.
No matter what you pay them.
Please read this book, and put it into practice. Your workers will thank you. Your customers will thank you. Your superiors will probably fire you.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
As someone who "grew up" working in technology over the past 21 years, I can provide you with first-hand guidance on how to handle your transition. I have been blessed to hold virtually every type of technology position along the way and am not above revisiting those tasks when necessary, even though I have been a CIO for the past 5 years. If you feel I can help, please drop me a line at emcee1963@hotmail.com. ...And by the way, best of luck to you!
is: Becoming a Manager: How New Managers Master the Challenges of Leadership (Paperback) by Linda A. Hill It's a great book because it follows what happened to others in your position: performers who become managers. There are no holy principles of management that waste your time. Instead, it helps you understand what the transition is all about: instead of you doing the work, you are going to need get the work done through others. It is also easy to read after a long day of work
Make sure you have time to get your stuff done and remember that someone else is doing what you used to do. Help them a bit if they need it, otherwise let them do their job. I know this will be hard and it is very tempting to tell them to just let you do it. You're a manager now. Let them learn how to do it. As painful as that may be. Here is a real asset to you - show them how to use google properly.
Keep up with technology. Things are moving - Virtual machines, san storage, blades just to name a few things. You need to learn to tell if someone is a master of the technology or they are BSing you. Beware of sales weisels, aka cool aid vendors. Don't sweat it, you can do it.
Good luck
While you're on wikipedia, why not read up on this eye-opener.
too bad you were unable to do the same.
1) Update Resume
2) Find new job
3) Quit
OR
3) Negociate a $$$ more than your manager. Then you keep doing something that requires technical skills, remain marketable, and still get paid what you're worth.
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...
1. Forget all your IT knowledge, & learn to struggle to attach an email. This is essential. A truly great IT manager says "magic" when shown for the 457th time how to attach a file to his email messages.
2. Learn to ignore all proposals from the IT dept. IT depts. can't be trusted in providing for the best interests of the company that employs them. Backup up WAN links etc. are a waste of money. Everything works well so lets save that 300 Euro per month.
3. Be certain to use the resources & skills of your IT dept. to engage in personal vendettas & covert ops. against regular, hardworking employees of the company & even fellow managers, for the simple reason that you simply don't like them. If, & only if an employee / fellow manager is being sneaky & using the internet for their own pleasure, be sure to hunt them down & crucify them in a manner that would send chills down the spine of a hardened Roman Legionaire.
4. Outlaw the use of company laptops at home, as this is an abuse of company property, but be sure to ask the IT dept. for a spare one when you're sent on junkets which are merely designed to increase your employability after your retirement, all paid, of course, by your current employer.
5. Again, the handing out of occasional favours such as network cables & phone leads etc. for users to take home is totally forbidden, unless of course they are for your own use. When this is the case do feel free to provide the IT dept. with detailed specs. such as "cable of 28 feet in length", or even get the IT dept. to spend the best part of a week rebuilding your trashed home pc. When doing this you will be honing the skills of those you manage, & this is, of course, in the company's best interests.
6. It is also important to correctly understand the productivity of those you manage. If Jack completed 2 projects this week & Jill completed 5, Jack is obviously a lazy employee who probably has something to hide so we begin to implement covert ops.(see point 3. above) and Jill is a far better worker. Due to your lack of IT knowledge(see point 1. above) you will have to try to bring Jill around to initiate covert ops. against Jack. This can be done in a number of ways, but the most effective is to be nice & jovial with Jill for a number of days, because all IT managers know that those under them have the memory of goldfish & forget what their managers are really like after a day or so.
In conclusion it is really all about ignorance, contempt & misanthropy & leveraging your IT dept. to "value add" your own agenda. Good luck in your new job, I wish you well.
Yes, and here's one about you, you pusillanimous wanker.
It is disappointing to hear all the negative comments about management. The numerous assertions that managers are just dumb and worthless are dismissive to the point where they them selves have no value.
I have managed to one respect or another ever since I began working as an engineer. It usually came from the need to organize projects and tasks, I my self contributed greatly to with code and design. As my carrier grew, I eventually had to take on more and more complicated projects which required more overhead, took me farther and farther away from the down-and-dirty, and required me to cover more areas of projects I never had experience with. If I learned anything, it is that being a manager is a hard and long learning process because it requires one to take on more and more areas of knowledge in order to keep the larger picture of projects meaningful, well targeted, and integrated.
This is a hard decision to make. It means one will start to know a lot more about different aspects of a product, but be less specialized and proficient with each individual one. It also means that the people you manage will no longer understand the challenges you face and, lets face it, be ignorant to why certain decision are made. I know I was. In fact I've come to realize that I still am when it comes to my managers. Every time I took on a higher position I realized aspects of the projects I've been lucky to never consider before. I find refuge that my biggest supporters tend to be the most senior engineers. I think it is because they have been in my position before and know that I don't have production level tasks because my time is filled with research, scheduling, making sure all pieces of the process are performing efficiently, remediating team skill deficiencies and overall growth, looking for new opportunities for the team, and all the other stuff which "somehow gets done". In the end failure is put on manager's shoulders from both sides. Top management will look down for successful completion of milestones, while the project's team will expect their work to have a meaning in the big picture.
To some respect there are decisions which can be made to make the job easier. Having a good development process along with the infrastructure in place to carry it out helps a lot. In fact if it is a concisely scoped project and consists of self motivated people, it can almost run it self. Many of the open source projects rely these very aspects to function well. But, this isn't enough most of the time (at least in my experience) and many projects have scopes which pass well beyond development boundaries.
Yes there are many bad managers. In my opinion that is specifically because the job is hard. Good engineers often do not make good managers, just as is true for different fields. To do the job well, you must be good with people, good with the subject matter, good with the environment, and above all, willing to learn a lot of new things which you never even knew about before. Ow yeah, and be willing to realize that people will not know or understand just what it is that you do.
I'll add my voice to the others who recommended Scott Berkun's "The Art of Project Management".
I wish, wish, wish that this book existed several years ago when I was in exactly the same situation. This book is brilliant.
Just try to imagine a book on management that
- is devoid of hype and self-promotion
- is filled with genuinely useful information
- has no stupid slogans
- is enjoyable reading
- has exactly the stuff you need to know to transition from software programmer to manager
- prepares you for when things go wrong as well as right
Get and read this book!
1.Boundaries
Don't let your people talk to anyone else's. Make everyone talk through you. The less they know about the outside, the more they need you, and vice versa to the outside world. Job security!
2.Initiation
Make sure to put your new employees through hell before they are "really" part of the team. I suggest documenting the entire code-base.
3.Customs
Create customs like beer Fridays or High Fives in the hallway. Everyone wears red ties. Everyone wears T-Shirts that all say the same thing like "Team Tiger Rulez. LOL." If others follow suit, change yours.
4.Ideology
Tell your people what to think. Every meeting should start with some set of ideals. Beat it into them. For example; "Ruby on Rails is the only technology worth investing your time in."
Fisrt, congrats.
Second, some books.
1) The Mythical Man Month - it's as good as everyone says
2) The leadership pipeline - Will tell you what you have to give up in order to be a manager
3) Crucial Conversations - will really help you when dealing with lots of different personalities (some of which may be your own)
After that, constantly remind yourself that you're new at this and you're not going to be perfect.
Say the same thing to your people.
After that, when in doubt, support your team. Always.
Politics, Culture, Food?
Three things about becoming a manager I suggest:
- first remember that managing is not coding
- I STRONGLY recommend reading "Behind Closed Doors - Secrets of Grest Management"; longer than 2 hours but easy VERY practical reading
- the Perl motto applies - there is more than one way to do it. You need to adapt ALL management practices to what works for you and your team
Get the job done: master project management. PMP style training of any sort is good. Know what to expect and what is to be expected: The American Management Association is a good resource for career-minded people. Nowadays, you manage projects, not employees. You manage expectations. Let HR deal with the humans.
I have read many of the replies and one thing I have not seen anyone pick up on is that your going to be in a dual role. I found myself in that exact situation 2 months ago. It is not easy. Putting the management BS aside, and trust me there is way too much of that, 2 roles will kill you.
Here is my average day now.
6:00-700 AM - log in from home to check up on everything from last night (global company). Answer questions from the tech's and other managers.
8:00 AMGo into the office and make sure everyone remembers to do the tasks assigned to them.
8:00 AM-12:00 PM - Meetings (all damn day long)
12:00-1:30 PM - Listen to lies on why people arn't getting their work done.
1:30 - Sneak in a little lunch, if possible
2:00-5:00 PM - Meetings
5:30-6:00 - Start to work on my own work.
7:30 PM- Call my wife to let her know I am on my way home.
8:30 PM - Leave for home.
I told them I would only do this for so long. Many times it is much better to have a person as a manger, and a tech as a tech. I will promise one thing, you will have a better sense of what a good manager can do. They are like the computer support, if they do their job good, you never hear from them and begin to think it is a very easy job and one that is not really needed.
Google "joel on software" and read his blog archives, thoroughly.
The guy seems to have a good take on software management - that
your job is basically to clear a path in front of the developers
so they can get their job done. He also has a book on hiring.
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.
Remember, back when you were just starting out as a developer, when you realized the gulf between studying CS and doing it?
:)
Yeah.
You need a mentor, someone you respect, who has done that and is willing to give you the benefit of their experience. Someone to whom you can take -any- problem and have any conversation, no matter how painful. Have there been any managers in your past for whom you had more than the usual respect? Maybe you've come across individuals from other organizations at meetings and seminars.
Good luck with that. I did this ten years ago and... well, it was a mistake for me. After a few years I realized that I had absolutely no interest in management as currently practiced in the US of A, but I hadn't kept current technically (tough to do when your're working as hard as you can at something else!) At the least, having a foot in both camps should give you more flexibility. But being lured by the money is hard to resist. Use the force, if you have to.
Rb
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.
If you are fulfulling the responsibility of an Architect, you better damn well understand the following:
1. Networking - in particular how many simultaneous connections can be handled by a given machine, network device, and throughput of same. This has implications when designing systems - particularly high performance systems (multiple threads, multiple users, and large data transfers). What are the various strengths and limitations of various protocols (http, h323, IP, UDP etc) considered. What are the network security implications of the design?
2. File Systems and Storage - how many inodes does a given filesystem partition contain, will the app outstrip local disk usage so a NAS or Storage Area Network is required?
3. Databases and Directories (LDAP) - how much overhead does oracle require vs PostGre vs MySql etc and what are the tradeoffs with regard to performance and cost, what is appropriate to store in a DB versus a directory, and can you extend the directory as needed or does the vendor(s) own the key attribute tree? etc..
4. Hardware - when will a workstation suffice, when do you need a server, when do you need an array of servers, when do you need a high performance computing cluster or super computer and what is the difference (in cost, energy consumption, and performance)? Will you need to include backup and restoration gear, laboratory and testing gear, and development gear in your plans?
5. Tools - what are the tradeoffs for various proprietary tools, and FOSS tools? What are the best tools for the job? What does your teams know how to use efficiently? Will the cost of retraining be worth the benefits of a different approach?
6. Project Management - you have to keep the PMs straight, particularly if they did not come out of the development side.
7. Finance - you have to be able to justify the costs associated with your decisions and understand how they impact the overall business case (can we afford to do X)?
This list just scratches the surface - these are areas that I have seen architects and system developers fall down on the job - too many times. Attempting to grok systems architecture is a life long learning experience.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
There are two kinds of managers out there. There are managers who manage people and there are managers who manage projects. Some positions combine both but not always. From my experience good coders are rarely good at interacting with people, so eventually they are not that good at delegating parts of the projects and end up doing most of the work themselves. I would personally recommend checking out http://management.about.com/ it is a good resource to start with.
The lubrication in anal sex does not necessarily enhance the act (unless it's a warming/scented stuff), but does ensure that the pain is diminished if not removed. It helps the process to go smoothly and quickly while being better received by all parties involved. It's not absolutely necessary, but going on without it can have dire consequences if things are too large or move too fast.
/.
But I suppose the car analogy works better for
(I had to think long and hard before deciding to post as AC.)
The One Minute Manager by Kenneth H. Blanchard and Spencer Johnson
Of course, you have to take my advice with a grain of salt. I was a manager for a while, then happily transitioned back to being a developer -- over thirty years in IT now. As a manager you're really only as good as your worst subordinate. I never could get used to having my success be outside of my own control. That's probably a personal limitation.
I hope that you do well in your latest career choices.
The worst thing that will hit you is that, as a manager, you'll find your time much, much more fragmented than before: you'll handle hundreds of request, projects and queries each day so managing your time effectively in very small chunks becomes much more important.
Read up on things like the "Gettings Things Done" (GTD) methodology. It will save you many a headache if you use something like that right from the start.
The alternative is that you'll be overwhelmed and will fail to do anything well.
Your not alone, everyone feels this way.
I have been a product manager, code monkey, and entrepreneur, and of all the hats I have had to wear across all of those positions, by far the least appealing to me is managing programmers - it sucks.
My advice is to remember never to over-praise or fail to recognize achievement - analyze the work done carefully, and respond honestly and specifically.
As for the work of being a manager, you should always know what your reports are working on each week and should check in with them at least that often in a face-to-face, even if its just a cube stop - avoid doing this by email or phone.
From the point of view of people under your supervision they will like objectives (SMART objectives, where S.M.A.R.T. stand for Specific, Measurable, Agreed upon, Realistic and Time limited) while also they will like appraisals from time to time based on the initial objectives.
From the point of view of upper management they will like an Excel spreadsheet showing income/expenses, so that any period is better than the previous one, because you are improving your organization.
When one is ready, such a decision should not arrive by surprise ....
IANAL but write like a drunk one.
I just started reading The Accidental Manager. Seems well written into Chapter 2.o pchik/dp/0814474497/ref=pd_bbs_sr_1/105-5551658-54 83621?ie=UTF8&s=books&qid=1188474628&sr=8-1
http://www.amazon.com/Accidental-Manager-Gary-S-T
If you could get it started it would run, but not well and not for long.
I will have a sig when the market demands it.
I would highly recommend that you find a management coach. They'll be able to give you personal instruction and help you develop your management style. You'll also get immediate feedback on specific areas you'll want to develop.
These people get most of their business from referrals, so they are greatly driven by results.
The former are merely ignorant - they have the option to learn, to delegate, to bring in someone who does know; the latter really are idiots.
At the bottom of the
With increased responsibility, there should be proportionate recompense.
My suggestion is: if you are not getting SUBSTANTIALLY more money for managing, then you should update your resume and start looking. Same if you ARE making more money, but your workload has increased a lot. You should be getting more for what you are doing now, rather than getting more in exchange for more work.
I don't think you can find anything better. Especially for the price.
This is free weekly podcast about management. They are in top-10 rated business podcasts all the time, and thousands of people checked their stuff in the field. Successfully.
I'm sorry, but if you were surprised to find you are a manager, I would advise you do not take this job. First, the company is setting you up for failure since they didn't talk to you about it ahead of time and ask if you wanted to manage. Second, putting you in a dual role of architect and manager is ticket for failure. How can people give you honest constructive criticism of architectural problems when you are also there manager? Also, the fact that you are asking now, after being in IT for 15 years about good books may be a sign that you have actively avoided managment, even to read about it?