4 ms·
I'd go about it like so. 1. Start on a high note, take the team out to lunch / dinner and start to get to know them. 2. Don't force any changes, they will lik
by dahdum 8y ago
I'd go about it like so.
1. Start on a high note, take the team out to lunch / dinner and start to get to know them.
2. Don't force any changes, they will likely resist and you'll lose any budding support. Forcing a code review workflow is likely to demoralize them, and will be perceived to be slowing down dev that's already behind.
3. Work longer hours than anyone. You need to earn their respect, being seen to work insane hours is the fastest way to prove your commitment.
4. Do one on one interviews with everyone, and listen listen listen. They know what's going wrong.
5. Strive for consensus, and become their champion in relation to upper management.
6. Never denigrate any member of the team, even if they are exceedingly incompetent. Work with them to assign tasks they can complete.
7. Heap praise on every good process and success you see.
8. Never claim any credit for yourself, ever. Make sure the CEO understands this, and doesn't praise anything you do in front of them.
- cubano 8y agoThis is an outstanding list and should be required learning on every software manager's todo. I can't tell you how important 3. is.
- davnicwil 8y agoMy personal feeling is actually quite different. I tend to respect a leader much more as a professional and as a person if they are able to deliver really great work within sensible working hours, leading by example with effective and sustainable work habits.
- dahdum 8y agoI differ, OP is a foreign gun entering a company already in crisis. They will undoubtedly be paid much more than the local developers, and absolutely cannot be thought to work less than any of the team they hope to lead. Things are certainly different if you are an established leader building your own team in a stable company.
- blunte 8y ago#3 - in some cultures a subordinate worker will almost always choose to leave after their superior. This is probably not the outcome you want/expect. #8 - you need to find a balance between crediting your team and making it absolutely clear to management that your contribution was critical. Obviously you do want to avoid the latter in front of "your team"; but in closed doors or in management-only meetings, you should not sell yourself short... which means sometimes you need to just boldly say, "I recognized X and chose to guide the team to do Y, and that resulted in Z (a good outcome)".
- dahdum 8y agoFor #3, my thought would be working from home and on the weekend. Committing code, updating tickets, emailing outside of work hours. Management type tasks are easy to handle off hours like this. As for credit, yes totally agree. In a group setting, they should be the first to take blame and the last to take credit though.