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?"
"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?"
1. Treat others as you would expect to be treated
2. Never assume that anyone has nothing to add to a conversation
3. Keep your shit together; be organized.
4. Realize that even if you follow the above rules there will be politics and CYA that will make you miserable from time to time.
Seriously though, once you've semi-transitioned into a management position, don't expect to have any time to do any other work during normal hours.
You'll spend 120% of your time in meetings, doing paperwork, reporting on issues to upper management, delivering managements responses to underlings and never have a moment to yourself.
You'll find yourself doing your own tasks after that, so that a normal 40 hour week will become a normal 60 to 80 hour week, and you'll still feel like you're falling behind.
Who is general failure, and why is he reading my hard drive?
Take some time to reflect on the managers you've had experience with. List the good and bad traits they had. Think about the hard decisions they made well and the ones they made poorly. Then see how you think your style of management can benefit from those lessons. (This assumes you have already thought about your style of management, otherwise that is step one.)
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.
Good resources for you:
Some tips:
YMMV, and good luck!
Dude, no one gives a shit about you life.
Nobody gives a shit about your comment.
Don't speak for the rest of us, particularly when you don't have the minimal courage required to associate your whining comment with a Slashdot handle. Counterpunchers like you a dime a dozen. Talk when you have something useful to contribute. Otherwise, shut your yap. You may learn something.
Read the EFF's Fair Use FAQ
This can be true in a passive sense, when a good manager acts as a blast shield to protect the team from things such as
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I agree.
A good manager = a good buffer.
If you have buffer overflow there will be a heap of unwanted behavior from your employees.
"A government is a body of people, usually notably ungoverned." - Shepard Book Quoting Malcolm Reynolds
She's not an idiot. She's just not technical. There is a big difference between the two.
:-)?
Yes but the difference is that an intelligent, non-technical person will know that they are beyond the area of their expertise and stop and ask a technical person about it whereas an idiot will happily charge in without a clue. Hence she is an idiot.
More on topic my advice to a new manager would be the above: do not be afraid to stop and ask questions from your underlings. You might be worried that it makes you look ignorant but it is far, far worse to not ask questions and do something really stupid like the aforementioned judge. Think about it: would "Judge Asks for Technical Advice from Expert" make Slashdot headlines (assuming Zonk is on holiday
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 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." If you think about it, it's true: your employees have to be certain they are doing the right thing, be certain of the requirements, and be certain they will get the support they need. Your customers have to be certain that you're meeting their needs. If you can do all those things, than you're probably doing a good job.
I also agree with the "good manager = good buffer" statement, but I'd even take it a step further. Great managers have requirements analysts, support personnel, etc. get the information from the customer. Then they form a plan and assign tasks to their development team. In my experience, this works rather well.
I'm totally going off on a tangent... back to your original question. Karl Wiegers' Software Requirements and More About Software Requirements are both geared towards requirements analysis, but have a lot of info that anybody in IT (and especially project managers) would find pretty useful... Both are worth checking out. I've also heard lots of praise for The Mythical Man-Month, but I've never gotten a chance to read it. Besides those, I would skip books on general management techniques and go straight for anything on software engineering or project management. The R.S. Pressman website probably has even more recommendations.