As a development manager, what are your first steps joining a new company?

Question

I've recently been offered my first position as a development manager. I would be taking over a team of 4 at a small software development shop with the mission of creating structure, and improving efficiency/process. I'm seriously considering the offer, and would like to hear your comments or additions to my list below.

First day?

• Meet the team
• introduce myself and my values
• start positive relationships.

First week?

• Learn about the product, and employees, both developers and executives.
• Get a feel for the way things currently work.

First month?

• Decide which agile methodologies are best suited for the environment
• install and configure tools to track progress and improve quality
• Train management and staff on Agile principles
• Create a backlog as Stories
• Run first sprint

Answer 1

With no prior experience this is likely to be a tough ride. Listen, listen, listen to your team and others. There is a lot to learn for you. No two teams or companies are the same. Even with prior experience there is not cookie cutter approach to being a development manager or a project manager.

What I typically do when I start working with a new team is this, and these are also my main recommendations (there is a universe of other things to learn and know in that position):

• Make sure the team gets to know you. Try to be neutral at the beginning, e.g. by saying that you have no intention to fix something that is not broken.
• In the first three months mostly listen to your team but in particular to stake holders. Continue doing what the team did in the past. Try to identify the biggest pain points. Address these carefully, always involving your team and the stake holders even if you have the final word on all decisions.
• As you learn "how to drive the team" you will get more experienced and confident. Still always work on the biggest pain points.
• And don't try to introduce Agile methods for the sake of it otherwise you will be seen as the one fighting a religious fight even if that is not your intention. Introduce Agile techniques if and when there is a concrete problem where it makes sense to try them out at a small scale. If they work do more of them. If they don't try something else.
• Always keep in mind that the commercial aspect rules. Without a commercial link to all decisions you won't be in business for long. Just because a tool or a technology looks good on your resume doesn't mean your team or your company will be successful. Always link all decisions to (pressing) commercial requirements. Be customer oriented and obsessive about that.

In general try to stay flexible and adaptive and learn as you go. Communicate a lot, within your team, outside your team. Don't give up as it will take time become really good in this job. Sometimes you will have to take steps back. That is fine as long as you work with the team and not against it. Good luck!

Answer 2

I cannot add too much to the previous two answers by @the_reluctant_tester and @John, except 2 things:

1. I got the impression that this will be your first job as a leader. If so, I strongly recommend to find a mentor in your organization, because without a mentor it will be a tough job. Maybe the guy who gave you this job can be a good candidate or a fellow development manager, but it cannot be a team member. A mentor can help you with the colleagues, technology and corporate network.

2. By the way, networking. Besides working with the team try to focus on building good relationships inside the organization. If have a new idea or plan you won't be able to follow through without them.

Answer 3

I would give more than 1 week to "Learn about the product, and employees, both developers and executives. Get a feel for the way things currently work." , in fact it would take much more than that to, I would give atleast a month for the following things -

1. Listen to your team, listen long & hard and learn their greiviances , what do they expect from you as a leader ,, what do they expect from the organzation ? what they want changed and why ?

2. You will need time to understand each team member's working style ? , you would need to make personality profiles in understanding them , talk to your boss

3. You will need understand what are the business needs and expecation of the management from you and your team , what are the gaps between these needs ? why are these gaps ?

4. If possible,It would certainly pay to spend sometime with your predeccesor

Only once you have got a handle of these things , you can move into the "change implementation" phase , as reffered as point 3 in your plan. I would not be "biased" towards A process until I have been through a step 2 of your plan , exhausitively

good luck

Answer 4

Suppose in step 2, the "learning about the product" phase and the "get a feel for the way things work" phase, you find out that the culture isn't agile-friendly or that the product has some aspects of it that rule out agile as a good methodology?

Suppose you find out that things are working really well as they are?

In the last step, you've proposed solutions and taking actions without knowing what the problem is. To me, that's very concerning, and if you take that approach, you're likely to kill the very first goal you mentioned, building positive relationships.

Other than that and your very short timeline, I think you get the right idea. Your job is to learn. Learn how things are done, learn what the problems are, learn what works, and learn the culture. However, don't rush in there with big plans to force the team to stop doing things that are already working just because you happen to like Agile methodologies or Basecamp, etc.

In short, don't force them to adapt to you. You must adapt to them. Doing otherwise will create a lot of tension, distrust, friction, and push-back. Do learn and listen, and find out from the team what they think works and doesn't work and what could solve the problems. Any changes implemented should happen gently and slowly, over time, and should appear to be made by the team and not by you.