In a week I will start a new job at a manufacturing company managing the development of a new eCommerce site. The company scores about a 3 on the "Joel" test. I will inherit 3 programmers who developed the company web site and do general IT programming.

I have the grey hair and credentials to have their initial respect but I'm an engineer, not a manager. I'm looking for practical advise - particularly for the first 90 days - on how to establish myself, keep the team together, and move forward.

  • 10
    Just find the toughest one in the room, beat him nearly to death, and everything will be fine after that. Feb 9, 2011 at 0:09

7 Answers 7


Remember that you are an engineer first, not a manager, and make sure they know it.

Engineers respect realism and understanding generally and hate unrealistic demands, or unfocussed, ill-prepared actions. You will probably know this, as you state you are one.

As the manager, you will be piggy-in-the-middle and probably have a hard job juggling between the respect of those above you and those under you, it is not an easy balance in a lot of companies, particularly in hard times.

I will say this, if you favour the engineers, your working day will tend to be good and respectful apart from meetings, though your career may suffer. If you favour the management, then you may get promoted and favoured, but your workers will probably hate you and the atmosphere will be poor at times.

  • I second "Engineers respect realism and understanding." Doesn't mean you have to be buddy-buddy with the programmers, but just knowing their boss has his feet grounded in reality helps an engineer respect them. Feb 9, 2011 at 2:17
  • @BinaryMuse: Personally, I find it impossible to work with people who I am not good friends with. You spend more time with them than your family as a rule.
    – Orbling
    Feb 9, 2011 at 2:19

I would perhaps look at increasing the Joel Test score. Introduce elements that are missing from that list that you think would make life easier. For example, if they don't have a bug database then introduce one.

Note, don't do it for the sake of it. Do it if you think that introducing the new aspect to the programming team would be beneficial. Use the Joel Test as a guideline.


I don't know...if it was me I think I'd come to work, with the assumption that every team is different, and just learn for a while. I'd try to figure out what's working for them, what isn't, and maybe suggest a few minor changes on the way.

On the other hand, you could always decide a bunch of changes you want to implement before you ever even get to work on your first day, force them on everyone, and generally beat them down into submission.

I guess it's a matter of philosophy.


Listen to your employees as well as your managers. Judge others on how they produce not on their personality. Let them know exactly what's expected of them and stick to it. Try to stay centered and don't take things personally. Prepare three envelopes.


Books could be, and have been, written about this. I give these two to new managers:

Leading Geeks by Paul Glen, et.al. http://www.amazon.com/Leading-Geeks-Manage-Deliver-Technology/dp/0787961485/ref=sr_1_1?ie=UTF8&qid=1297216248&sr=8-1

Becoming a Technical Leader by Gerald Weinberg http://www.dorsethouse.com/books/btl.html


Fight your instinct to come in and immediately start making or talking about changing everything. As a newly minted manager from an engineer background the temptation is going to be to adjust the whole team to develop around your own personal style.

At least until you have some rapport with the team you should keep your ideas to yourself and actively solicit input from the existing team to show that you value their input. Then when you need to start setting up some structure it is more likely to fit the culture better and also be accepted more readily.

Short Version: Talk less, listen more. Then listen some more. And after listening some more, confirm understanding by explaining back to them what you see. Then start making suggestions.


I'd recommend implementing some means of agile development (SCRUM?). It tends to keep teams well organized and on-time for short or longer sprints in which code must be completed.

You can find plenty of resources online with respect to agile development and SCRUM.

Here's a good start: http://www.pragprog.com/titles/jtrap/the-agile-samurai

Good luck.

  • 5
    Yeah, step one for new management: walk in on your first day and change EVERYTHING. Feb 9, 2011 at 0:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.