What is the most important thing to do for a new technical manager or lead?

Question

Managing a software team is a different proposition than managing software. Most of those who become manager or lead of a software team are typically bright software developers who have done a great job over the years writing and managing code.

However, transitioning into management or lead position proves to be difficult to them because they tend to manage people the same way they used to manage code. That is one reason why they dont transition into good project managers.

In your opinion, what would be the most important thing that a new software manager or lead should do as he makes the transition?

Answer 1

Get new business cards. :-)

Answer 2

Find out what your new boss wants and do that.

I'm not joking.

Answer 3

read. a ton. if you haven't already.

jeff atwood's reading list
joel spolsky's reading list

Answer 4

If you have a team lead who manages people like he/she manages code, you had better do things for that person. The two are such different mindsets.

I've had team leads in the past who were previously full time coders, and a few of them have been excellent leaders. The quality of leadership has almost nothing to do, IMHO, which coding ability (technology knowledge is a different story).

If they aren't good with people, best to work on that. They need to take good care of you, so that you can perform miracles for them!

Answer 5

1. Go on training courses on:

   • Time management
   • Presentation skills
   • Man management

2. Accept that life is going to change. The attitude of other staff toward you will change dramatically. management will often expect you to immediately start towing the management line without question. Developers will often stop seeing you as a source of useful experience and knowledge and instead as an interfering waste of time.

3. Take wife/ husband/ partner out to dinner with the extra money from the pay rise :)

Answer 6

Once he (or she) has made a decision on what to change and what not to change in the department: Communicating it clearly and ASAP to the team.

Answer 7

Read Richard Whitehead's excellent book Leading a Software Development Team (sanitised Amazon link). Especially, the couple of sections on what to do when you first arrive.

Then follow that up with the DeMarco & Lister bible Peopleware (sanitised Amazon link).

HTH.

cheers,

Rob

Answer 8

Learn how to communicate effectively with people not only with compiler.

Answer 9

Get and read this book:

http://www.pragprog.com/titles/rdbcd/behind-closed-doors

Behind Closed Doors Secrets of Great Management

by Johanna Rothman and Esther Derby

its an excellent book covering the basics of moving into the management of technical teams. Easy to read and doesn't insist that there is only one correct way to do things rather it focuses on establishing effective communication processes while keeping management off the backs of the developers.

Both Rothman (http://jrothman.com/blog/mpd/) and Derby (http://www.estherderby.com/index.html) have websites with more information and calendars of their training schedules.

Answer 10

I wholeheartedly agree with some of the other comments about people who may be excellent software engineers or otherwise very technically gifted usually not translating terribly well on the whole into managers (they might end up being very good leaders more often, but being a good leader doesn't always map one to one into being a good manager, either).

However, that aside, it happens to be a transition that I have made, and I happen to think I'm pretty good at it (although that's probably some of that software engineer egotism bleeding through... :)), and this is my take on it:

• The hardest, and, in my opinion, single most important thing you have to do is to LET GO. Realize that even if you are more technically knowledgeable than some of the people working for you in certain areas, if you aren't actually down in the weeds all day every day like they are, it's simply impossible for you to understand the intricacies of complex problems at the level they do. That's what they're for. Help them, ask questions, and make suggestions, but don't try to control things or tell people how to write software or otherwise implement things. Even if you're right, they won't learn as much if you do so and they'll have more respect for you if you just let them do their jobs.
• By and large, you can still be "one of the guys," so to speak, and, really, that's good. However, don't be shy about letting people know that when it comes down to it, you have to be as objective and fair despite any personal relationships or friendships you have with them, and that you may have to do things that might not work out so well for them individually, but that you're paid to think about the company/team/group/whatever as whole and act accordingly. If you can't do this, you shouldn't be managing people, in my opinion, this is the main reason why we get paid more.
• Make sure you foster an environment in which your employees will never hesitate to challenge your ideas or decisions initially. You need them there for that, you're not going to be right 100% of the time, and getting back to my first point, they will know more about the specific technical and implementation details than you nine times out of ten. Make sure they know that they are encouraged to call you out on things, but you expect them to back up their arguments, and, at the end of the day, even if they don't convince you and you go another way, their input was valued and appreciated, but... you need them to do it your way instead.
• The specifics of this will vary wildly depending on your particular environment, but ensure that you do have measures in place and appropriate tools/etc. around to ensure that you're doing things "right," so to speak (in other words, defect tracking, revision control, etc, etc) but make it as painless and easy for them to use as possible, and make sure that you can easily quantify the benefit TO THEM (whether direct or indirect) of doing so even if they do think it's a pain in the butt sometimes. For example, even if for whatever reason you have to use a defect tracking/project management system that isn't 100% ideal for developers, but it works better for people in product/sales/whatever, it might work out better for them because they'll have less salespeople stopping by their desk in the middle of the day interrupting them. If you can't quantify the benefits to them, you should probably change things so that you can.
• Make sure it is clear to your employees that while you work actively to do everything you can to ensure that they have a fun, safe, ideal work environment and that fun & games are ok, at the end of the day you expect results. You don't necessarily need to explicitly go out and say this, and in many ways, it's probably preferable if you don't. If you do everything else right, it sort of comes with the whole package.
• Be firm, but fair. Missed deadlines/subpar software aren't good things, but we all know that "stuff" happens. Instead of getting worked up about a missed deadline, get worked up about finding the problems and issues that led to that deadline being missed in the first place. Work to correct those actively and visibly, whether it is something internal or external to your team.

Could probably go on, but looking back up at that "Write really long answers on technical management philosophy at work" isn't on my list, so I should probably quit while I'm ahead! :)

Answer 11

There are many good books on management, read them as you get time. But the secret is not management, it is leadership. People like good managers, but good leaders can motivate employees to accomplish just about anything.

Answer 12

"What would be the most important thing that a new software manager or lead should do as he makes the transition?"

As if there possibly can be just one such most important thing that suits any newly promoted software manager or any circumstances. Bad question. However, actually, having been in that situation and having got burned I can confidently say, that there is such one, most important, the ultimate answer to the ultimate question, the thing any newly baked manager should do or rather not even attempt doing.

Just reflect on your past experience as a developer, what would be your golden rule, the ultimate and most important thing you should do (or rather not even attempt doing) when faced with the task of maintaining and improving a complex, highly coupled and awfully important system you do not really understand? Correct. If you do not understand how and why it works do not change it. Full stop.

Being a good programmer would you change a piece of any production code without fully understanding what it does, why it does that, what are you trying to achieve, how are you going to achieve it and how are you going to check there are no side effects? Doubtfully so, especially if you are really good programmer, not until you gain enough understanding and confidence that the change is safe and there is a contingency (plan B as they say).

Manager deals with a multifaceted system of people, resources, tasks, explicit working procedures and tacit practices, politics, statutory issues, company policies and the list can go on and on. The last thing you want is to break it, disrupt or bring to a halt. At first just let it work, do smallest possible changes, have a plan B, and see what happens, learn. All that good stuff any experienced developer would do when assigned to maintain and improve a production system they do not fully understand.

Answer 13

One of the most important tasks of a manager is to eliminate his people's excuses for failure.

-Robert Townsend

Answer 14

I have to say this is something that has interested me for a while, why do we take people who are good at their jobs and promote them to managers, which they have no idea about, wouldn't taking a passing butcher and giving him the role have the same sense ?

My GF is a successful IT project manager, and has absolutely no idea about anything IT, but she can manage a good projects (she works for one of these large insurance companies)

Apart from the about and back on track, recognise that management is a skill in it's own right, and do the same research if you were learning a new programming language

good luck .... and get some new business cards

Answer 15

As a manager you will have to adopt a brand vocabulary that you will be required to use with the business units. You will be asked to be on-the-spot translator for you technical team, as you are the bridge between mysterious processes of software creation and the often ambiguous, murky, ill-defined world of business processes.

The trick will be to retain your analytical instincts and attention to detail, while turning off your natural vocabulary, as your instinctive choice of words will often make you business unit com padre's eyes glaze over. Presentation of ideas will need to be tempered and in plain English. This will be your biggest challenge.

Answer 16

Here are some of the techniques which I feel are extremely helpful. These are over and above the skills that you may have learned through your development experience.

• Do an honest estimate of the project(s)
• Set clear goals and milestones for the team
• Make sure the team understands the methodology and processes that are being followed and (more importantly) their importance
• Set an example
• Identify individual's skills and put them in appropriate role (I usually prefer complimentary skills)
• Keep the team motivated
• Give team members opportunities to express their concerns
• Feel responsible for the Success or Failure of the project

Answer 17

Stop doing what you were doing before being promoted (ie: programming)

I'm currently reading "The First 90 Days", and while its not oriented exclusively towards technical managers, It certainly gives some great advice.

The most important lesson for me: Stop doing what you were good at before being promoted (ie: stop programming, stop marketing, stop designing). We're all naturally inclined to do more of what we're good at, and being good at it was probably the reason we got promoted in the first place. But managing requires more than that, and only by stopping to focus on our previous role, we can be better managers.

Answer 18

Read this book "Peopleware"

http://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439

Get to know the people reporting to you.

EDIT

The job is now to do everything possible to keep these people productive. That does not mean micromanaging or figuring out ways so "motivate" them.

When I started my first time at management after being a developer I would sometimes ask myself the question "What would Mike R (a previous manager of mine who was fantastic) do"?

Answer 19

At least for a little while, don't plan to get any technical work done. You will be responsible for overseeing how everyone elses work come together and meet up againt senior management's expectations. And, long term, expect to have less hands on influence on the lower level details of design.

I made the mistake of focusing too much on my technical output. Add a few other non-work related problems at the time, I was not a useful/effective lead, and was demoted from my lead role as a result. Your role as a lead is to get your bosses get what they want (mostly information on schedules, progress, and overall project oversight/awareness) - do that, and you will be fine.

Answer 20

The most important thing would be to become a facilitator between your team and your boss (or boss team). How: To spend more time understanding what both of them want.

Maybe you can go-through the book 01 Minute Manager, this might be a good head start.