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?"
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?
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?
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.
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.
Mod this guy up. It may be a shallow seeming title, but it is filled with a highly compassionate and true set of advice!
Much like The Art of War is really about how to make Peace, How to Win Friends and Influence People is not about how to make others just do what you want... it is about understanding the elements of social conduct which make us tick. It's about how to inspire the people you work with. How to hold your tongue, when you truly shouldn't say anything. How to accept the good ideas of your coworkers, and how best to speak when their idea isn't so great.
It's one of the most valuable books on social conduct that you can ever read. Check it out.
- DaftShadow
Good resources for you:
Some tips:
YMMV, and good luck!
Can't recommend it enough really - it helped me plenty.
http://www.amazon.com/Peopleware-Productive-Projec ts-Tom-DeMarco/dp/0932633439
Good advice all around in the posts above. A site I've found to be pretty insightful is Rands in Repose. He's also a new book titled "Managing Humans". Check it out—I'm a fan.
-- Ryan Price http://www.ryansdesigns.com
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!
Note that the PMBOK is made by the PMI, so when you see PMI, PMP, or PMBOK, you're pretty much talking about the same thing.
PMI is the institute
PMBOK is the material
PMP is the certification
Glad to hear that an MBA stressed PMBOK
It's si-LAY-us, you Silly Ass!
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
A good mentor would also be important. Start having lunch with an old boss that you really liked. This is the best advice in the topic. Your job is to optimize the output of the people below you, often by making their jobs easier. (It's no use paying someone lots of money to order pens and paper from Staples, etc...) They will tell you what they need, you just have to listen and empathize (DIFFERENT THAN sympathize, managers often have to make some very un-sympathetic decisions). A great manager is one who balances those needs with the needs of his/her bosses while making both parties happy.
I highly recommend you subscribe to the RSS feed for Harvey Schachter's Monday Morning Manager (or just read the "blog" http://www.theglobeandmail.com/blogs/wschachter). It's a weekly column from The Globe and Mail and is a smorgasbord of brilliant tidbits for just about anything a manager might encounter. He does a great job bringing together helpful information from a variety of sources, and this leads to a lot of information that you can dive deeper into should he touch upon something highly relevant to your situation. (This invaluable resource was given to me as a tip when I asked a very similair question to yours to a very experienced colleague, i.e. someone who has been a manager or executive for longer than I have been alive.)
You should read Lee Iacocca's book Talking Straight http://www.amazon.com/Talking-Straight-Lee-Iacocc
I also had a organizational behavior class at school and I had the chance to read a book called "Management of the Absurd" by Richard Farson. I really thought the book was excellent. A few of the things that I learned that have stuck with me are:
1. All tasks automatically expand to take up the time allotted for their completion.
2. If you only know how to use a hammer, every problem looks like a nail.
3. Praising people does not necessarily motivate them.
4. In a well functioning team it is often difficult to determine who the leader is.
5. The best leaders often "serve" the group. Capturing info on the white board or calling on someone who has been quiet in a meeting.
6. When I am trying to prevent a problem from happening and take an action, I now understand why my action actually causes the problem to happen that I was trying to avoid.
7. In order for a management technique to be effective it must be contrasted with its opposite. Also as soon as it is discovered by your staff that you are using a technique on them, it will cause the opposite of what you intended. (Nobody likes to be manipulated)
I could keep going, just read the book, or better, get it on audio book form. Listen to it in the car like I do when things have gone horribly wrong and you need a pep talk.
Joel Spolsky is in the same boat as you (as am I, for that matter). He was great technically, so they made him a manager. http://www.joelonsoftware.com/ has some wonderful tips about managing technical folks.
But really, the best advice I have is: Quite and find a job where you can still write code. Management is dreadful, especially if you are one of those people who likes to do things themselves.
I've been a development manager for five years now after holding architect, software development, and software consulting positions for a decade. Here is a list of things that new development managers will learn the hard way -- regardless of how perceptive or proactive someone thinks they are:
1) Your first priority is doing what is right for the company. If you are just trying to always "be the great guy" to your team, you are a horrible manager and horrible for the company. Do the right thing for the company and the rest will follow.
2) You are not an architect anymore. - Let the architects and software developers design and write the software. Your job is to ensure that the team has what they need to do their job.
3) You are not a coder anymore. - Put practices in place which allow the software developers and architects to keep code quality high.
4) You are not an individual contributor anymore. - Your own achievements are solely based on the achievements of your team. You did your job well if you team did a good job.
4) You have to give negative feedback. - People need to know when they are screwing up. If somebody has body odor, you need to tell them to clean it up. If somebody is consistently late, you have to tell them to get their asses in on time. If somebody is a negativist, you have to tell them to get a better attitude. If someone is surfing too much, you have to tell them to stop. If some coder is going off in the weeds chasing butterflies and losing track of a feature, you need to tell that person to get back on task. The worst kind of conflict is ignored feedback.
5) You have to give positive feedback. - When somebody does a good job, tell them. If someone kicked ass on a feature, tell them. If someone finds a hairy defect and fixes it, give praise. If someone works long hours one day, give them a free day off, or give them a gift certificate to take the family out. Whatever.
6) The "open door" policy is lazy bullshit. You have to have frequent informal one-on-one meetings. - People need to venue to vent, ask questions, voice concerns, et cetera. All people. Even the quiet ones. Be proactive and give your team a predictable place to do that. You will offset a lot of potential risks this way.
That's all I can think of off the top of my head. I was a shitty manager at first. Over the years, I have learned each one of the above lessons -- usually after a serious screwup.
Good luck to you new software development managers. I truly believe it is the hardest job in software engineering. But stick with it. Once you get good at it... it can be very fulfilling.