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?"
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.
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.)
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.
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.
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.
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.
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
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.
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?
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
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."
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".
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'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.