15

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
| improve this question | |
  • Is this a project management position or a development manager position? – jmort253 Mar 11 '12 at 3:48
  • Development Manager. – Justin Mar 11 '12 at 20:01
  • Maybe picking nits here, but it is 100% a-okay to answer your own question... may I suggest splitting the two? That way we get to vote on the merit of the question and answer separately? – Al Biglan Mar 12 '12 at 3:00
  • I only answered it to show that I had given it some thought myself, and give a reference point to compare to. Vote on the question, discuss the answer. – Justin Mar 12 '12 at 4:53
  • I am starting a development manager on Monday. I know this post is a bit old but wondering how things worked out for the OP and whether some of the advice here rang true. – user18004 Aug 1 '15 at 5:49
14

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!

| improve this answer | |
  • 1
    +1 especially for "stay flexible and adaptive and learn as you go". After a few days you might find your time estimates are way off, as are the possibilities for things you can/want to do. It's good to have a plan, but it's even better to be able to change that plan and still move forward. – jcmeloni Mar 11 '12 at 18:16
  • Thanks John, I have been told that the pain points are bad estimates and late notification when deadlines will be missed. This may be my first job as a development manager, but I've been a team lead on small and medium software teams for about 10 years. In my experience, those pain points are caused by lack of bite size iterations, and not enough visibility into progress outside the team. Although I'm not a religious agile preacher, it's methods do lend themselves to easing those problems with short sprints and big visible story boards and burn down charts. – Justin Mar 11 '12 at 20:09
  • Listening is big. Figure out what everyone agrees needs to be improved and start there. After the low hanging fruit, you can work on the more advanced stuff. – MathAttack Mar 11 '12 at 20:43
  • 1
    +1 for Be customer oriented. IT is not an end, but means to reach customers' end. – Tiago Cardoso♦ Mar 12 '12 at 12:58
  • 1
    This covers most of the same points I would advise as well. I would add to this "don't prescribe - describe instead". When you help the team find what they consider problems, try to frame and describe the problem in ways that allow them to solve it, even if it's not the way you would solve it. They will probably own the solution better, react to it working/not working and own any tweaks needed, and it avoids placing you into a position of authority. Edit: just realized how old this post is! :) – Jeff Lindsey Aug 3 '15 at 13:20
8

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.

| improve this answer | |
  • 2
    an up vote , for "finding a mentor" – the_reluctant_tester Mar 11 '12 at 8:47
  • It is my first job as a "manager". I've been a team lead for a long time. Great idea on the mentor, I've got many of those already, and always looking for more! – Justin Mar 11 '12 at 20:11
  • Great first point. One commonality amongst failed PMs is a lack of mentors. Its the only shortcut in improving judgment. – MathAttack Mar 11 '12 at 20:44
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

| improve this answer | |
3

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.

| improve this answer | |
  • +1 for pointing out the very real possibility for killing the primary goal. – jcmeloni Mar 11 '12 at 18:17
  • 1
    My hope was to get them excited about new processes, rather than force it on them. You're right, I just have a CEO's vision of what's wrong, which can be out of touch at times when they don't have a ton of technical experience. I'll be sure to move slow and get consensus as much as possible. – Justin Mar 11 '12 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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