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?"
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.
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.
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.
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
But because she's an idiot, she's very angry and confused when she finds out that RAM just. doesn't. work. like. that.
She's not an idiot. She's just not technical. There is a big difference between the two.
Your advantage is that you've got the technical background
For now. You have a technical background for now. I used to be an engineer, and a pretty good one at that. I was certainly one of the top technical people at the company when it came to understanding and solving customer problems. I've been a manager for two years now...and my technical skills are shot. I know enough to keep up with conversations, but ask me to do any real down and dirty troubleshooting and I'm back to being a babe in the woods.
It's not that I dislike the manager role; it presents some interesting challenges. But don't rely on your technical skills to save you when you're flailing as a manager, because within a month or two your former co-workers and now underlings will be passing you by.
It's "no one," not "noone." Who the hell is noone anyway?
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
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.
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
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?
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.
In fact, the judge made a perfectly reasonable order which all three of you have completely misunderstood before happily charging in without a clue.
So, who are the idiots?
Getting back to the original question, this exchange certainly demonstrates why managing developers (and IT people in general) is so difficult. I don't think there's any other field where people have such disproportionately inflated assessments of themselves and so much misplaced contempt for others.
What I'm listening to now on Pandora...
I also ANAL, but I am in a leading role in the technology management of my company and deal with legal inquiries regularly. I would say that Yes, the judge could order you to do this. No different than the fact that companies are required to maintain copies of chat messages, which also are generally transient.
Because it is physically possible to do what is being requested by the judge, either in your example or the ruling in the case, then a judge can order you to do it. Just because it means a little work on behalf of the company is not a valid reason for not doing it. If the company could prove a severe financial burden would be caused by the ruling, then they might (again, IANAL) be able to argue against it. I don't think that is the case here where the judge is basically saying to add persistent logging capabilities.
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".
Why didn't you just assign her a different position? She may have been better suited to tasks other than development, such as testing (as in manual testing if need be - not writing unit tests). If she was willing to take a salary cut, that would have made changing her job even easier. Even if she had spent her days bringing the other developers coffee, she would not have cost the company multiples of her salary to keep employed.
Quality, performance, value; you get only two, and you don't always get to pick.
I had to look past the sunbeams and imagine the impact both on the firm and the guy if he stayed on. It wouldn't have been good for us, or for him. The guy should have been a life coach or a priest and by not taking the step of sacking him I was keeping him from a chance to do good somewhere else. Sucked having to tell him.
Then later I found out he'd fabricated everything in his resume in the first instance, coached his friends to act as references (who looks past the phone number?) and screwed up a bid that would have employed another dozen peeps. Sucked finding that out.
Advice? Don't assume you know everything about people, just like you never assumed you knew everything about software or hardware. HR people -- good ones -- can help, and so would a bit of reading about psychology, body language, every possible fad or truth about knowing people from the best sources you can find. People are a lot more difficult than software. Learn your subject, grasshopper.
Do not mock my vision of impractical footwear
Because being a manager does not mean you can create new positions.
Right on! One of the things I need to do as a team leader is to identify and reduce the damage from incompetent programmers. Incompetent programmers not only have less productivity, often they have negative productivity, the grand parent post is good example. Letting them work on the code creates more work for the rest of the team.
When firing the incompetents is not an option, due to emotional issues (as the GP post) or otherwise, even putting them to do nothing is better than letting them work on the code. It is tough to explain to higher-ups, you have established a good trusting relationship, sometimes you just have make up some work for them, my favorite is documentation. "Capture all screens of the system and write brief description of them in this document. Have a glossary of every field label displayed." can make them busy for the whole project without endangering a line of code, and you end up with a good document for the almighty thud effect.
Oliver.
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.