5 ms·
"no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming" --> none of these things prevent code from shipping
by herval 8y ago
"no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming" --> none of these things prevent code from shipping, per se. I know it's convenient, as a first time leader, to focus on the technical aspects, but from your description, it seems there's underlying non-technical issues you might want to get familiar with first.
On the technical side, I recommend _listening_ a lot before making any suggestions. _Maybe_ it's all backwards, and there's _always_ a better way to do it, but showing them you understand how they work _first_, then help them push something - even a small win - out of the door _first_ will get you a lot more "street cred" than trying to mandate things out of the gate.
If you're looking for some literature, "Five Disfunctions of a Team" and "Culture Code" are good starting points on how to tackle cultural aspects (and how to be accepted as a newcomer "playing the boss", which will also be your case).
Other than that - leading teams is difficult, leading teams _well_ is an incredibly frustrating/counterintuitive exercise, but a huge growth position :-) Good luck!
- boothead 8y agoGreat suggestions (and book suggestions)!
- cam3ham 8y agothis. I've seen so many "senior leaders" jump into a project and try to implement these types of "textbook processes" when in fact they don't solve any of the issues at all. The project just gets dragged out, etc.
- charlieflowers 8y agoThe first thing that crossed my mind was "Seek first to understand, then to be understood." You almost certainly will find some people who already long for what you're going to advocate.
- faizmokhtar 8y agoIMO this would be best. Don't go gungho and fix everything when you first join in OP.
- dchichkov 8y agoMaybe start introduction with your pull requests, not destructive criticism?
- gwbas1c 8y agoI doubt there's been any real code reviews. If there were code reviews, they were probably treated as formalities. (Without really understanding the context,) one thing to do is just emphasize code reviews. There are many ways to do it. In 1-1s with team members, set expectations for code reviews. (Read through every change, question anything that looks odd, you're supposed to request changes.) In team meetings, pull up an open pull request and start asking questions. I've worked with a lot of people who come into my team assuming that the code review is a formality. Some team members adjust, and others leave for more sloppy assignments.