First, if I were in your shoes, I would approach this from a different direction. You are onboarding yourself, not the team. If you approach it from the opposite angle, you will piss off the people you need to be most helpful.
The first step is to introduce yourself. This will be supremely unhelpful, but maybe someone with a better memory/filing system can chime in with some more help. A few months ago, there was a post on the front page about developer READMEs. There were a couple of great examples in there written by new managers to introduce themselves to their new teams. My Google skills are failing me now, but I'm sure that I'll find the article about five minutes after I can no longer edit this post. :)
I wish I could give you that link because those readmes are a great way to introduce yourself to a new team.
Aside from that, I'm a big fan of changing absolutely nothing and getting your hands dirty as soon as possible. There's nothing better than a manager who comes in with respect for how you have done things and helps solve some major problems. You will get bonus marks if you're very humble. I would pair with members of your team and get them to teach you the system. Thank them, praise them when warranted, and try your best to avoid playing those shitty developer "whip it out" games. Keep note of the developers who play those games. They might be lacking confidence, or they might be a cancer...
I'm not saying that you can never change things because you will. But it's dangerous to change things until you understand exactly why it was done the old way. You'll be surprised how often things that seem really dumb are actually necessary.
Then, try to set yourself up as someone who will advocate for your team. It's hard to prove this without actually doing it. But, you have a new job, so you'll presumably want to avoid ruffling any of the feathers that hired you. This is a tough one to balance and I'd be lying if I said I had any specific advice beyond going with the flow and being careful.
If you do this for two to three months, you'll have the capital to really lead.
Finally, good luck. You're making the hardest transition in our industry, but I believe in you. You'll be a great manager - posting this ask HN is a very good signal. Have fun, be you and kick ass!!
Listen to the team. Spend time observing and getting to know the systems, the people, the processes. Don't try and make major changes on day one because you cannot possibly understand the reason things work they way they do at that point.
1. Introduce yourself, your background, your values
2. Announce your intentions (see below)
3. As robertcope suggests, start off by observing and building relationships. If you have experience in what the team does, pitch in and get your hands dirty and learn the [codebase, processes, etc.]
4. A couple months of step 3 will accomplish 2 things: it will give you insight into what really is and isn’t working well for the team; and it will build you the political capital you need to get people onboard with changes. At this point you can start making suggestions. You should also by now be making yourself an advocate for your team’s needs with upper management.
The first step is to introduce yourself. This will be supremely unhelpful, but maybe someone with a better memory/filing system can chime in with some more help. A few months ago, there was a post on the front page about developer READMEs. There were a couple of great examples in there written by new managers to introduce themselves to their new teams. My Google skills are failing me now, but I'm sure that I'll find the article about five minutes after I can no longer edit this post. :)
I wish I could give you that link because those readmes are a great way to introduce yourself to a new team.
Aside from that, I'm a big fan of changing absolutely nothing and getting your hands dirty as soon as possible. There's nothing better than a manager who comes in with respect for how you have done things and helps solve some major problems. You will get bonus marks if you're very humble. I would pair with members of your team and get them to teach you the system. Thank them, praise them when warranted, and try your best to avoid playing those shitty developer "whip it out" games. Keep note of the developers who play those games. They might be lacking confidence, or they might be a cancer...
I'm not saying that you can never change things because you will. But it's dangerous to change things until you understand exactly why it was done the old way. You'll be surprised how often things that seem really dumb are actually necessary.
Then, try to set yourself up as someone who will advocate for your team. It's hard to prove this without actually doing it. But, you have a new job, so you'll presumably want to avoid ruffling any of the feathers that hired you. This is a tough one to balance and I'd be lying if I said I had any specific advice beyond going with the flow and being careful.
If you do this for two to three months, you'll have the capital to really lead.
Finally, good luck. You're making the hardest transition in our industry, but I believe in you. You'll be a great manager - posting this ask HN is a very good signal. Have fun, be you and kick ass!!