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.
If you aren't comfortable in your abilty to manage people you shouldn't do it. You will be doing yourself and those who work under you a great disservice. Good developer != good manager.
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.
Getting to Yes
First, Break all the rules
anything by Peter Drucker
"The first myth of management is that it exists. The second myth of management is that success equals skill."
Remember that, always.
Now ask your self, do you want to be a good manager, or a succesfull one?
If you want to be successfull, don't manage unless you absolutely have to. Allways do as the boss asks you to do and allways have someone else available to blame when it fails. Make sure the someone is not in a rank above you, make sure it's not a friend of the boss or his wife. In short, success depends on politics, not management.
If you want to do it right, again, don't manage unless you absolutely have to. Your management always interferes with people who are trying to get their job done. Let them do their work, don't interfere. Except when they don't do their job (properly) or when something prevents them from doing their job, that is when you should be there to manage things.
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
You seem to be implying that he should try it first.
My response is "why?"
Have you ever tried a career as a hair stylist? Why not? You never know, you might be really good at it.
You probably haven't tried it because you're not trained for it, you never studied for it, and most of all, you weren't interested in it. (My apologies if you really are a hair stylist, but given this forum's nature, I think it's a pretty safe assumption you aren't, so it should be a good example.)
It's the same with this guy's new position. What makes these morons above him think he has any skill at management, or even any interest? This seems to be a fundamental flaw in managerial thinking: that everyone else wants to be a manager too.
I have a technical job because that's what I studied for, and what I was interested in. If I wanted to be a manager, I would have majored in "Management Science" instead. That's the degree for people who want to manage. If companies want managers, these are the people they should be hiring. They don't move software developers into marketing roles; they hire marketing people for that. They don't move software developers into human resources roles; they hire HR people for that. They don't move software developers into finance roles; they hire finance people for that. So why don't they hire managerial people for management roles?
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.
1) Your people come first.
2) Support your people, come hell or high water.
3) See #1.
4) Keep any distractions that aren't absolutely necessary away from your folks.
5) Don't sign up for any critical technical work (you'll just slip the project).
6) Oh, in case I forgot to mention, fight like crazy for your people.
7) If your people are working overtime/weekends for more than a well-bounded, short term crunch, it's a sign of a problem, not a good sign at all. Kick your folks out and figure out what's going wrong, and fix it.
8) Don't constantly look over everyone's shoulder.
I'm no fan of Microsoft, but there's a book published by Microsoft Press by Steve Maguire or Steve McConnell (whichever one of them didn't write Code Complete) about technical management. It's actually very good indeed.
The combination of manager and architect sounds like a very dangerous one to me. It's going to be very difficult for you to get honest technical feedback from people who report to you, and architects need that kind of candid feedback. An architectural error that goes unchallenged for political reasons is bad news. When I was a manager, I once led a software integration team (a more suitable role for a manager), and even that caused some tension. Not with the person who happened to report to me -- she had no trouble pushing back when needed -- but with another engineer who found it uncomfortable when I had to go around and get commitments from people. I was actually selected for that role because initially no one on the team reported to me (I was the one leadership/management role who didn't have an interest in a particular component within the project), but things change...
But what about the people like myself who have been doing technical work for a long time and have recently been doing project management and liked it. Now I see that some management positions can be very rewarding where before I just wanted to do technical work. I know that isn't exactly becoming a manager but it is a step in that direction. It also turns out that I have a natural knack for that type of work so it suits me well and suits the company well. So it might sometimes be better for the ccompany to promote within before just bringing in a new guy to be the boss. Some people even tend to resent that in their company.
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.
I'll agree to a point either way. Today's society presumes some level of technical (computer) competence regardless of the field.
Also what is and isn't idiocy varies by the time. I'm sure you not knowing the basics of how to farm or handle livestock would have classified you as an idiot 300 years ago, but in no way does so now. Likewise at some point people didn't need to know how to type on a keyboard, at some point being illiterate didn't make you an idiot, etc. In the scope of a judge (or a politician), they should have a reasonable understanding of the topic at hand, be it through self research or expert witnesses. I know that's very wishful thinking, asking people to understand something when their decision impacts others (and it is their job to render such decisions), but hey, one can dream...
I am not an expert. If I am misled in something, please correct me.
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?
first off, i don't envy you --- i found myself in a somewhat similar situation recently where i suddenly became responsible for squeezing useful results out of three different subcontractors.
as for resources, first, and most important: it's been mentioned elsewhere, but finding a good mentor (preferably more than one) is going to be crucial. think of them as "man pages" for people.
second: i don't know what your personal organizational style is, but you're about to start juggling not just your own personal assignments, but all tasks of your entire team, plus all the "overhead" tasks of tracking progress, planning, etc. if you're not used to juggling about 5000 balls at once, get yourself the tools you need to help keep yourself organized. in my case, this meant a giant whiteboard with a matrix of tasks cross referenced to people and due-dates which i updated once a week after a brief status meeting.
third: start looking at your local community college's certificate / continuing education programs in business development / leadership development. in addition to more "standard" management classes, i would strongly encourage you to take a class on interpersonal communication, because you're going to discover quickly (if you haven't already) that people communicate very differently with management than they do with their peers. similarly, more junior employees have different communication styles and attitudes about communication than more senior / seasoned employees do.
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.
Nope, she's an idiot. Yes, she's not technical and no, that doesn't make her an idiot. What makes her an idiot is judging something technical when it is beyond her ability to do so.
SJW n. One who posts facts.
You never posted on /. until you did. You never drove a car until you tried. You never worked as a programmer until you got hired. Those, and millions more, are examples which make your question unnecessary.
A comparison to a hair stylist is useless because there is no transfer of skill from a programming job, for example. However an artist could do very well in hair styling, it pays well at the top.
Basically, a good coder knows more than he can implement with his own pair of hands. Then the coder gets promoted to a designer, team lead, a manager - where he is given an extension of his hands to do the job that he holds in his head and implements with help of younger, less experienced engineers. Any other use of his time would be a waste.
What makes these morons above him think he has any skill at management, or even any interest?
I would not be so quick to label people I don't know as "morons". It might be unfair, on occasion :-) Besides, if he was chosen out of hundreds of possible candidates then probably there is a reason to try him in this role? Managers are usually good at understanding people.
So why don't they hire managerial people for management roles?
Because most people, and even some managers, understands that Dilbert's PHB is not always optimal ;-)
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...
The point is that the oil only enables the engine to function well. It does not act as a fuel and it is not used to directly transport the power coming out of the engine. It simply makes the engine efficient enough that it doesn't overheat and melt itself.
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".
I don't think changing management every 3 months makes for a healthy company.
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.
As a coder, your job is to take technical requirements and turn them into code that meets those requirements. Those analytical skills will directly translate into management, but a bit of rethinking is required. Instead of needing to make the compiler produce the results you are looking for, you need to make the people produce them.
As far as retraining, see what Universities near you offer evening or weekend executive MBA programs. Unlike the Day programs that are geared for teaching management consultant grunts to be better management consultant grunts, the executive ones offer a lot of things for mid-level people that are actually in management. In an exec MBA program, you should cover Leadership, Financial Accounting, Managerial Accounting, plus basics in other areas like marketing and finance. An MBA, particularly in an executive format that has fewer elective options, tends to focus on "general management," it's like a liberal arts degree, it isn't specialized, but it designed to give you an overview. You won't become the company's expert on accounting or marketing, but you'll understand the jargon and big picture, so you won't be blown away when doing budgets, etc.
Subscribe to the Wall Street Journal, print or online, and try to read it a few days/week. This was what a friend with a technical background that got a job at McKinsey said she did to catch up on business jargon fast. A few weeks/months, and you'll find yourself less lost in business jargon, because you'll be reading things in the current jargon in context.
Some basic tips:
1. Your primary responsibility is to keep "the suits" from interfering with your team. If you have filled your team with good people, they'll get the job done, but if you let the top people meddle in your team, you will fail.
2. Understand boundaries with your staff... you have to balance a line between being "one of the guys" and being the "boss". Err too much on the former and you won't have the respect necessary to make the decisions, they won't appreciate that sometimes you have to make decisions that aren't up for debate... Err too much on the latter, and you won't get the honest feedback that you need to make decisions.
3. Use meetings regularly, usefully, and short. Long meetings annoy people, but you need some meeting time to keep everyone on the same page. Do NOT become the information funnel to avoid meetings. You need to know everything, but not be responsible for relaying messages. It's not the 1950s where everyone's secretary types memos to send up the chain or down the chain.
4. Build cross-functional teams wherever possible. Setting up a monthly meeting with your technical lead, someone from marketing, and someone from customer service to go over features, for example. If you meet with other leaders and get your technical people together, decision making will be stronger and you'll do better things for the company. Those that show leadership are more likely to move up the ladder.
5. Know where your time goes and why it is work. It is sometimes frustrating, because as a "code monkey," when you pulled an 80 hour week, you know what you did. You have some functions/classes/bug-fixes implemented. As a manager, your primary responsibility is keeping track of what is going on and communicating. This seems trivial to technical people, but is a lot of hard work and get be frustrating. If you spend a solid week in meetings with your team, superiors, and colleagues in other departments, it often feels like you did nothing, but that's your job.
6. Informal meetings are a great way to keep abreast of things, but don't disrupt people. Learn to have task lists. One of the worst senior managers I worked with had a tendency to call people whenever he had a question. I was trying to manage a small team AND do some technical work, and he'd blow my concentration constantly with calls e
I've found Colin Powell's Leadership Primer Helpful. Management is one thing. Leadership is far more valuable a commodity. You should be able to find it in google, I believe it's in the public domain.
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.
Very true... to be a "good" manager one just has to have general people skills and a list of deadlines/tasks. To be a "great" manager requires one to do a lot more, to actually motivate others to do better. In any event there are so few great managers that anyone that isn't a total choad should be just fine in a management position.
The only caveat: as a manager you have a lot more freedom to goof off... don't hang yourself with that freedom.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
Dickens' comes to mind here. You're at the door of a tremendous opportunity, but there's an equally unpleasant chance for failure. Number one, you've recognized that you're not feeling ready for the management role. To me, this is a great indicator that I think you'll surprise even yourself in the months ahead. The fact that you're worried about it shows you're not an ego-centric moron who thinks he's God's gift to project development. That said, I'll offer a few bits of advice for you to consider.
If the position is already settled, then go to HR and get connected with one of their senior specialists who works in training, development, or mentoring. Let him/her know that you're willing to step up to the plate, but that you are looking for some additional insight and help as you make the transition. Make it clear that you're looking for support, not some remedial "How to manage in 30 days or less" type material. S/he may be able to hook you up with another, more experienced manager in your firm who can help you during your first few months.
My second point really depends on WHO you will be managing. Will this be your current peer group, or a completely new set of faces? If your current peer group, I'd want to know what your relationships are like right now. Do they respect you? Do they come to you for help? If so, you'll probably fare better than some. If your peers don't think kindly of you, a malestrom could be ahead of you. If a completely fresh set of faces, only time will tell. Remember that your empoyees are going to want to feel you out as much as you are going to need to feel them out. My advice? Sit down with your new team on day one (or before). Give them your background and let them know what strengths you bring to the table (in some ways, this is like a final, non-binding interview). I would tell them that this is your first foray into management, and that you expect you'll make some mistakes along the way, but that you trust them to be open with you so that you may improve. Then (if feasible), announce that you'll meet with each individual briefly to get to know them better (this can be out of the "norm" for most men, but believe me that it goes a long way to establishing a good relationship). Keep those meetings short and light. Talk about the employee's interests and strengths. Many employees long for management changes with the hope that a fresh set of ears may be willing to listen to their dreams and aspirations. Try to learn the employee's preferred communications and learning styles (either by asking, or through observation). Ask them what was best about their last manager, or what they believe makes a good manager. Take note of what they say (mentally, or on paper)! You may not be prepared to provide the type of management they want, but having that list of expectations will give you a good starting point for your mentor discussions, or your time with your HR rep.
Okay. Enough from me. Best of luck to you in your new position. I would love to see an update from you in a year, to tell us what worked and what didn't.
I use irony whenever I can, but my shirts are still wrinkled...