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?"

Recommend

[blantonl (784786)]

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

Scott Adams' "serious" books FTW.

[Tackhead (54550)]

> A comb for the pointy-hair on the sides of your head and wax for the shiny top.

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.

Re:Scott Adams' "serious" books FTW.

[jskiff (746548)]

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.

Uh, no, she's an idiot.

[by Anonymous Coward]

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.

Re:Scott Adams' "serious" books FTW.

[Roger W Moore (538166)]

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 :-)?

Re:Scott Adams' "serious" books FTW.

[Otter (3800)]

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.

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.

Re:Scott Adams' "serious" books FTW.

[rah1420 (234198)]

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.

Are you in this field by any chance?

With a 4 digit Slashdot UID? [slashdot.org] What do YOU think?

Is there an obligation to understand the ruling?

[raehl (609729)]

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.

Re:Scott Adams' "serious" books FTW.

[Fred Ferrigno (122319)]

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.

The judge is a lot smarter than you think. The law is outside Slashdot's realm of expertise, so you get a horribly inaccurate summary and tons of +5 posts making jokes about putting a stick of RAM in the mail. All that was decided is that storing an entry in RAM constitutes making a record, even if it's of the most temporary variety. The law doesn't give a damn whether you store that information in RAM, on your hard drive, or on a piece of paper. On a judge's order, you can be compelled to keep records that would otherwise be destroyed, even if that means positive action on your part to create a permanent copy.

Re:Scott Adams' "serious" books FTW.

[dwarfking (95773)]

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.

Re:Scott Adams' "serious" books FTW.

[Glonoinha (587375)]

Screw that - in the world of legal expenses, a few sticks of DDR2 pc5300 is cheap. Next maintenance window turn off the server, pull the RAM, put it in an anti-static bag and send it to the other lawyers. Put in some new RAM, fire up your box and you're back on your merry way.

Re:Recommend

[smitty_one_each (243267)]

This is akin to saying the metadata in the data dictionary does nothing, only the rows in the tables matter.

Managers don't really do much of anything.

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

• scope creep from the customer
• asinine company policies
• other marauding managers
• 60 Minutes, and other quasi-human monsters

Re:Recommend

[no_pets (881013)]

I agree.
A good manager = a good buffer.

If you have buffer overflow there will be a heap of unwanted behavior from your employees.

Re:Recommend

[emcoffey3 (1076763)]

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 [rspa.com] website probably has even more recommendations.

Damn

[woolio (927141)]

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

Re:Damn

[marcello_dl (667940)]

"It is more advantageous to have a technical person doing technical work and an incompetent person doing managerial work instead of vice-versa"

Great, you broke it to him. Such tact.

Leadership and management

[Jim Hall (2985)]

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.

Re:Recommend

[jhines0042 (184217)]

I am currently finishing that same class. I agree, I have little clue as to what I was supposed to actually learn.

Mythical Man Month is a good read, I highly recommend it. Sure, it is full of things that you'll say "no duh" when you get done reading it, but you'll have read it and you'll know for certain not to make those mistakes. Plus you can whip it out when other managers ask you about software stuff and you'll look impressive because they haven't read it.

I would say this: be lazy. Try to avoid doing anything that makes more work for you and your team than is necessary. That doesn't mean that you should avoid work... it just means that you need to apply yourself and your team in the most efficient way possible.

I would also say this, don't be afraid to be certain of something and never be afraid to be proven wrong. If someone proves you wrong, concede the point and move on. Don't get stuck following a bad decision with justifications. Get back on track and move on.

Good luck too!

Management should be like lubrication in an engine

[EmbeddedJanitor (597831)]

The oil in an engine does not do anything that actively makes power, yet it helps by making the engine run smoothly and protects the engine as well as the parts inside it.

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.

Re:Recommend

[claytongulick (725397)]

When I was leading a development team I considered my primary role to be an umbrella for the developers. I did my best (frequently not good enough) to insulate them from the assorted pressures of the management team (political, revenue/sales, deadline etc...).

    All this is sort of avoiding the primary, fundamental issue: when you are a manager you have the power (and responsibility) to fire someone.

    This is the real rub. Can you do it?

    In my case, I came to a decision that I needed to fire a developer who was completely inadequate to the position. Only this: she was one of the sweetest, kindest people I have ever met. Additionally, if I were to let her go, she would be sent back to India - forcing her husband to also go back. It would have been devastating to them.

    So what to do? She was not able to perform her job function and it was costing the company revenue. On the other hand, I wouldn't have been surprised to see Bambi walk up and eat out of her hand whilst blue jays perched on her shoulder (this is how kind hearted and sweet the girl was).

    And I had to fire her.

    So I tried.

    And failed.

    I came to find out this about myself: when confronted with a tearful employee who says she'll do anything, including work for half the salary if only I won't fire her - I cave.

    This turned out, in the long run, to be one of the worst management decisions I've ever made. I agreed to keep her on at a reduced salary. She continued to perform inadequately but over time she had been with the company long enough that dismissing her wasn't an option.

    Everything she wrote ended up having to be completely rewritten and she wasn't learning from experience or coaching. Even though she was working at a reduced salary, she ended up costing the company a high multiple of her salary in lost productivity, alienated clients and rework costs.

    So what was the "right" thing to do in that situation? On the one hand, I felt a moral imperative to help this kind, tender and wonderful person. On the other, I had a commitment and moral responsibility to the company I worked for.

    Finally, I reached the correct solution: I resigned my position as manager of the team.

    As I'm sure you've noticed, I am personally not suited for management. I will never put myself in that situation again.

    Just because I'm a talented developer, doesn't mean that I have the ability to make tough managerial decisions when they are called for. Those are two different skill sets, and one of the reasons that I tend to not resent my managers. Firing someone is brutal, and unless you are comfortable with those types of decisions and _sticking_with_them_ I strongly recommend that you avoid the managerial gig and stay in development.

-Clay

Re:Recommend

[W2k (540424)]

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.

Re:Recommend

[Oligonicella (659917)]

Because being a manager does not mean you can create new positions.

Re:Recommend

[Nefarious Wheel (628136)]

Been there, done that, fired Bambi.

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.

Re:

[MightyMartian (840721)]

Managers don't really do much of anything. If you have minimal people skills then you should have no trouble acting as a manager

Indeed, that's why every manager, on the first day, gets a private meeting with Dr. Spaalzbad and his faithful assistant, Gorky, who proceed to remove his brain and replace it with shredded paper from Legal. Thus the new manager can becoming overtly concerned over the mundane, stupid and non-existent, say the most moronic things, and possess no evidence of intelligence.

best management book ever...EVER!

[by Anonymous Coward]

"How to Win Friends and Influence People"...it's a cheezy title, but an awesome book!

Re:best management book ever...EVER!

[cyphercell (843398)]

nah, he needs to read The Prince by Machiavelli, a thousand and two times.

Re:best management book ever...EVER!

[DaftShadow (548731)]

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 [wikipedia.org] 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

BEWARE

[TheSHAD0W (258774)]

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?"

Re:

[daeg (828071)]

It's often better to lead someone confidently off a cliff than meandering and starving through a jungle.

At least with a cliff, the pain is short-lived and they can replace you quickly.

The best advice won't come from a book.

[khasim (1285)]

It will come from the people to manage.

Always listen to them and hear what they're telling you.

Re:

[bhmit1 (2270)]

It will come from the people to manage.

A good mentor would also be important. Start having lunch with an old boss that you really liked.

Management is realtively simple

[DrRobert (179090)]

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.

Re:Management is realtively simple

[mcmonkey (96054)]

5. Be excellent to each other!

Re:Management is realtively simple

[Pseudonym (62607)]

You've clearly got no idea how to be a manager. Let me translate that for you...

1. Treat others as you would expect to be treated

Be people-smart with a view to enhancing workplace synergy.

Never assume that anyone has nothing to add to a conversation

Respect the value of human capital. Gift a space for discussants to talk through their concerns and add value to the dialogue.

Keep your shit together; be organized.

Work smarter, and keep on top of your key performance indicators.

Realize that even if you follow the above rules there will be politics and CYA that will make you miserable from time to time.

Prepare for, and manage, corporate disconnects.

There, now you're ready to be a manager!

Re:Management is realtively simple

[sasdrtx (914842)]

I just threw up. Happy now?

Re:Management is realtively simple

[Pseudonym (62607)]

I'm pleased the concept resonated with you.

Running shoes....

[GuyverDH (232921)]

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.

Your own experience!

[jimboinsk (802789)]

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

The Dilbert Principle

[John Hasler (414242)]

> Aside from 'Become a manager in 2 days' type books, what resources would you recommend I
> look to for guidance in this transition?

The above captioned book has everything you'll need to know.

Saving Private Ryan quote...

[TheLazySci-FiAuthor (1089561)]

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!

Development to Managerial - People skills...

[raydobbs (99133)]

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.

Mentoring

[bobdehnhardt (18286)]

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.

Good Topic

[Carcass666 (539381)]

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.

Look into certs

[squarefish (561836)]

Project+ [comptia.org] and CAPM [pmi.org] are geared towards your need, with the PMP [pmi.org] 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.

It's not complex, but not easy

[kbob88 (951258)]

I've been in and out of management over 20 years in technical work. I don't think it's mysterious or complex, but it's not easy either.

Good resources for you:

• The people you manage. Ask them and listen. They'll appreciate it, and probably give you good feedback. Remember to filter their comments, especially based on what you know about their personalities.
• The people you report to. Follow the advice above.
• Courses at a local college. I wouldn't overdo this, but if you could find a good course on organizational politics and power, that might help. Or it could really suck. Ask around.
• Slashdot. Ok, maybe not. But other discussion groups might help. Plus you'll be fairly anonymous, and won't have to censor your questions as much.

Some tips:

• Listen more than you talk.
• Determine what makes the people above you tick and stay on their good side. To them, you need to appear committed, competent, friendly, and loyal, but not fawning and flattering. And don't bug them too much.
• Cultivate good, friendly relationships with your staff, but..
• Set guidelines for your people and stick to them. You've got to enforce the rules. In the end, you're the boss.
• Be organized and take good notes. It'll save your ass someday.
• Develop relationships outside your group and those above you. You need to know what's going on so you don't get blindsided.
• Set metrics and reward achievement.
• Hire good people and ensure they stay. Can't emphasize this enough. And it's really tough to do.
• Don't be afraid to get rid of bad people. Not only is their performance bad, but they're lowering everyone else's performance too. You can't be nice to all the people all the time. If you can't do this, you should just be an architect.
• Raise issues early. Don't be afraid to deliver the bad news. Don't try to hide it. But you've got to have a solution or path forward. As one of my old bosses said: "Come to me with choices not problems."

YMMV, and good luck!

Be sure you want to do this

[geophile (16995)]

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?

Rands and Joel

[OutlawDrake (219223)]

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

Rands on Management: http://www.randsinrepose.com/cat_management.html [randsinrepose.com]
Rands's Book: http://managinghumans.com/ [managinghumans.com] (Direct to Amazon: http://www.amazon.com/Managing-Humans-Humorous-Sof tware-Engineering/dp/159059844X [amazon.com])

Joel on Software: http://www.joelonsoftware.com/ [joelonsoftware.com]

Good luck! It's great to hear about people who care enough to want to do it right.

The hardest job in the biz...

[javabandit (464204)]

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.

But not worse than ACs bitching and moaning

[Infonaut (96956)]

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.

Re:

[Grishnakh (216268)]

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