3 ms·

I won't repeat what others said but you have no idea how common it is for a newbie to come onboard a new team and think "everything is wrong, it needs to be fix

by _8j50 4y ago

I won't repeat what others said but you have no idea how common it is for a newbie to come onboard a new team and think "everything is wrong, it needs to be fixed and I will fix it". No doubt the things you said are things that can be improved but they were done that way for a reason and you already mentioned budgetary constraints, so it sounds like the existing team made the best of what they were given and you will have to become like them and adapt. Improve what you can as opportunities arise but migrating away from a 10k line nginx to PHP might sound like a good idea for example, but, you will spend resources on something that won't make a noticable difference? Instead, you can implement the PHP router for new endpoints for example. The worsr thing you can do is come in with that attitude and expect the team to be onboard. You will only alienate yourself, try to understand why things were done the way they were (never architected but put together piece by piece over time). Make them feel heard and and pace yourself with any changes.

DSMan195276 4y ago
> The worsr thing you can do is come in with that attitude and expect the team to be onboard. You will only alienate yourself, try to understand why things were done the way they were (never architected but put together piece by piece over time). Make them feel heard and and pace yourself with any changes. Yep, I agree 100%, the last thing you want to do in this situation is piss off the three people who know how this thing actually works. IMO the real thing OP needs to decide is whether he's willing to fix the whole thing himself or if he wants (needs) the existing devs to help. If he wants to go it alone then he can take any of the advice given here and do whatever he wants. But, if he wants the team to help then his main priority is to understand their current processes and how they get things done, and then look at where more modern practices can be introduced to improve things for the team and get them to buy in. Sure he said their "resistance to change is huge", but mine would be too if someone joined my team and determined literally _everything_ needs to be changed immediately (even if it's completely true). I would bet they would be much more receptive to realistic suggestions after you get an understanding of their process, gradually building towards a better one. And if they're not, then OP should probably just go look for another team/job. It seems pretty clear that 'actual' management doesn't care about this (which is to be expected, I mean they apparently have a functioning product bringing in 20m) so as much as it sucks the situation is what it is.

by _8j50 4y ago

DSMan195276 4y ago

> The worsr thing you can do is come in with that attitude and expect the team to be onboard. You will only alienate yourself, try to understand why things were done the way they were (never architected but put together piece by piece over time). Make them feel heard and and pace yourself with any changes. Yep, I agree 100%, the last thing you want to do in this situation is piss off the three people who know how this thing actually works. IMO the real thing OP needs to decide is whether he's willing to fix the whole thing himself or if he wants (needs) the existing devs to help. If he wants to go it alone then he can take any of the advice given here and do whatever he wants. But, if he wants the team to help then his main priority is to understand their current processes and how they get things done, and then look at where more modern practices can be introduced to improve things for the team and get them to buy in. Sure he said their "resistance to change is huge", but mine would be too if someone joined my team and determined literally _everything_ needs to be changed immediately (even if it's completely true). I would bet they would be much more receptive to realistic suggestions after you get an understanding of their process, gradually building towards a better one. And if they're not, then OP should probably just go look for another team/job. It seems pretty clear that 'actual' management doesn't care about this (which is to be expected, I mean they apparently have a functioning product bringing in 20m) so as much as it sucks the situation is what it is.