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.
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!
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