For example. Make code reviews mandatory and lock down branches. No PR? Then the code doesn't get merged. Part of PR checking is test coverage and has to pass. Remove direct access to servers and environments and make deployments go though CI. Every PR must be tied to an issue.

Don't leave it up to them. Make it happen.

You don't need to be an asshole about it, but just make it happen and provide instruction on how it all works.

My role is to normalise the SDLC (from inception to sunsetting), whether it's IaC (TF, Ansible), Java, .NET or JavaScript - on Linux (DEB/RPM), Windows and containers.

Most likely I'll step on some toes, although my argument is I'll step on everyone's equally, for the benefit of all.

The team is the people not the org chart.

You went nuclear.

Threatened those people with losing their houses, access to health care, and going hungry over deploy methods and pull requests.

You’ve squandered whatever goodwill and trust you might have had.

It is time to learn from your mistakes and move on. That’s not how to treat people.

Leaders negotiate.

Good luck.

Negotiation and persuasion are very important parts of being a wise leader in technical and creative fields, but it sounds like OP followed exactly what you advocated to no effect.

None of us were in the room with OP and know both sides of the story, but it sounds like he gave them 2 months of the very kind persuasion and negotiation that you're advocating, and the employees persisted as willfully insubordinate and not following the processes that their boss wanted to enact.

Do you keep negotiating for another 2 months? 2 years? Or do you have to make a choice at some point that people aren't even attempting to try and learn the processes you were hired to implement?

Maybe simply because firing people is expensive. But probably not solely for that.

I mean they hired the OP to fix the team not destroy it.

They could have fired them all instead of bringing the OP in.

The OP is showing a naïveté regarding ordinary organizational reality and managing up as poorly as they are managing down.

Fire the developers who aren’t using tests? Now you have two problems.

What's required to fix this situation is for someone to manage up and down the hierarchy, and it doesn't seem like you're going to be able to pull that off in this organization. Maybe someone with more experience could make it happen but it's probably just a shitty company and it's not worth the effort.

The fact that the CTO and directors let this situation fester for years is a sign that they're clueless and/or disinterested.

Best alternative would probably to create a new team to replace the previous team's services one-by-one with well-operated versions. And then fire the previous team entirely. Probably not a very fun job.

If you have better options, take them. I would.

My two additions would be starting weekly one-on-ones or if you are already doing them, using them to roll out changes individually with each contributor

This allows you to individualise your approach but will also help you get to know your team better.

No one is so busy they can’t spend 30mins a week having a chat.

The manager-tools.com has good resources to help with rollout

Secondly, figure out everything you want to change and then pick three. Dont change a single extra thing until those things are done.

This team really needs a manager. Someone who can take responsibility for the problem, someone who has the power to fire and hire if need be. And someone who can mentor new tech leads like you. Who can help them with the communication and persuasion parts of the job. It sounds like there is no such person here.

It's not a great situation for you. The ideal time to start being a tech lead is with a group who trusts you, or with management who can help you gain this trust. You don't have either of these things.

This team also sounds like it's a low priority for management. They don't want huge outages, sure, but it hasn't been worth management taking a very active interest for the past couple years.

So, basically, it's just not a great situation. It's certainly possible to stick with it, and if you do, I suggest being more focused. Just deal with the outages, don't expect to be able to put best practices into place very quickly. Especially since this team sounds like it has been accumulating low performers over time.

You haven't fallen into a trap. The people that are working there are probably talented but socially inept. Make the changes you think you need to make. I suggest you move away from the coding role - if they want to act like children then treat them like children. Set op CI. Do the code reviews and make sure that things can't get pushed to production without you reviewing it. I don't think they are deliberately going after your commits - but that they just know more about the system than you do. Basically take the dev-ops role. It also helps you to learn more about the system as a newcomer. When doing code review you will inevitable have to make contact with them and they will have to learn to work with you. And they can't say no since their code wont get published to master otherwise.

If I was you I would ask myself a question if I'm qualified enough (I mean people skills) to take over such established team, where I could potentially be perceived as unwanted addition- in such case I'd probably not take the challenge.

Get the CTO involved and ask him to join the meetings for a week.

Redo all the discussions you had before, in the week.

See what the end result is.

Re-evaluate

Tbh. I don't think the management is "bad". No one got fired, as far as you mentioned and they are trying to fix it with you.

The problem is that you don't have the "majority vote". With the CTO ( who might disagree on some things with you too, I hope), you will counter that issue in most cases.

If senior management undercuts you, move on.

I'm curious, are they paid developer rates, or engineering rates?

To that point, do they not understand that without "the basics" on their CVs their market value is diminished, perhaps greatly?

Has anyone said *exactly* why they are against adopting Best Practice A or Best Practice B?

All that asked, if they are - for all intents and purposes - *intentionally* putting the company (read: your income and the income of many others) at risk then firing is in order.

But!!! Speak to someone in legal first. You're going to need documentation to avoid legal issues.

p.s. As a web developer, I've left more than one agency because of lack of "the basics". I'm simply not comfortable seeing clients get charged "we follow best practices" rates and they get far less. Does your team not understand how many others would love to work sonewhere that embraced "the basics"? Boggles my mind.

But you said they were trying to keep the lights on. This reads like they were mostly doing bug fixes. They were not deploying new functionality? If that is the case, it means you got suckered into being a scape goat for a piece of ancient tech that no one cared about until it blew up. Your team are already looking for other jobs.

Are those cool things may be beneficial for some abstract project. It certainly may be.

Will those things be good for any project? Certainly not.

How do you think software development existed before all those things were invented? Code was better, systems were more reliable. And there were no managers solving “issues “ with buzzwords

> This situation caught up with them in the past few months with many outages that caused close $1m USD in damages. Thus why leadership felt they needed a tech lead to steer the ship.

No. It's a difficult task, but not a trap. You just seem in over your head.

You've got a dozen wild dogs. You cannot break all of them at once. No trainer on the planet could, even if you started shooting each them to try and intimidate the survivors. That's psychopathy, not leadership. They won't respect it, and will react to it aggressively.

I mean this in the kindest way but you seem too reasonable to have the spine to rule through fear (it's a good thing), so unless you're prepared to replace the entire team at once, firing any of them is just going to turn everyone against you.

Mass execution of inconvenient subjects isn't an option for dog trainers. So do what a dog trainer would do:

Focus on isolating the one of them you think would become compliant with the least amount of trouble. Groom, coach, and bribe them to do things your way. Give them special privileges, discreetly. Do whatever it takes to turn them into an ally.

You know how new restaurants hire people to stand in line so it looks busy? That's what you need to do. Nobody wants to go to an empty restaurant, nor do they want to adopt a tool or workflow nobody else is using. Since nobody's doing it, nobody wants to do it. You need a trailblazer.

Getting the first one to line up is the hardest part, sets an example that "this is what we're doing now," and makes breaking the next one easier. Eventually you'll achieve critical mass, where the ones you've broken will police the rest to fall in line because the noncompliance of the holdouts inconveniences them. Once that happens, you're done-- they're doing things your way and it's too late for them to go back, so slowly dial back on the privileges and coercion or they'll take advantage of that too.

> Fast forward 2 months. They are pushing back hard on any new proposals to adopt CI, tests, code reviews, issue tracking, you name it.

> I've reached my breaking point.

> I proposed to fire/transfer some of them.

2 months is nothing, and that's a lot of changes for a team that's used to doing things their own way. I'm not saying you're wrong to suggest any of those changes but a leader can't expect to lead purely on their superior knowledge and experience, they also have to be able to win the hearts and minds of those they're leading.

I guess the question I would ask here is why should they trust you? You've told us why you don't think very highly of them, but why should they think highly of you?

Did you expect to come in all guns blazing telling them they're doing practically everything wrong and that they're the problem and for them to approve of you? Do you think it's surprising given what you've said here that they might be a bit suspicious of you and not want to do anything you say?

Again, I don't know the situation, but reading what you've written it sounds like you need to take a step back and get to know the team before you decide they're putting the company at "huge risk" in your first two months on the job.

My suggestion – pause all of the changes you've suggested so far and arrange something fun to get to know the team (during work hours) – maybe go to the pub for an afternoon or order pizza or something. Take that time to ask them what their problems are and try to help them the best you can with those problems for a few weeks.

When you feel you have some respect from them try to propose a single change. Make your best case for it. Give them time to think about it and offer their thoughts. If they have concerns, make them feel like you appreciate their feedback and ask them for suggestions. If they provide useful suggestions give them credit for it.

I think your problem here is that you haven't won the hearts of your team and it sounds like you're not involving them in any of the decision making. If you want to make significant changes without challenge you need trust, and you clearly don't have that.

That said, if you want to do this without winning their trust, then yeah, you'll probably need to fire some or all of the team and build a new one. If the team is truly as bad and as unreasonable as you suggest that may not be the worst idea. But again, I don't know without knowing you or the team. But just reading this I see some red flags in regards to your leadership style.

Sorry for being a bit critical, I'm just trying to be as honest as possible given what you said here. Either way it sounds like you're in a difficult position and you need to put your own well being first. You've clearly taken a lot on and sometimes it's just not worth it, especially if you don't have the power you need to make some of the decisions that you might need to make.

It sounds like you are coming in and wanting to create a lot of extra work for everyone.

I have dealt with engineers like this before. You want to follow every single best practice, create automated testing and do everything “right.”

Creates incredibly massive extra work that is non value added.

These sound like some lazy ass engineers who don’t give a shit.

My guess is this team has had two years doing things a certain way, and you are trying to get them to do a lot of extra work and they are going “yeah fuck that.”

Probably they won’t get paid more for restructuring their entire code base.

I would guess most would rather leave then do that.

So they are just going to bicker with you.

Generally speaking, when you join a job there is a grace period where you decide if you can help them or not.

Or if you want to help them or not.

The reality of software engineering is it doesn’t make sense to EVER rewrite everything from scratch. Ever.

It sounds like your management are not on board with firing people or changing anything.

Sounds like either:

1. Give up and collect a paycheck and find something that seems useful to do but doesn’t actually change much

2. Make a play at changing your management style.

It sounds like you are trying to dictate to them what to do.

That NEVER works. EVER.

It sounds like you are coming in and telling them what to do.

LOL.

An alternative approach is to embrace a facilitation driven approach.

A facilitation driven approach looks like this:

1. Do lots of research 2. Come into the team with options of different approaches 3. Have the CTO and the team and whoever meet 4. Say “here are the problems and here are some options for solving them” 5. Facilitate a discussion around the options and get people to voice any opinions or support or concerns 6. Try to get the group to head in a direction of progress

My personal opinion, sounds like you are trying to dictate your approach and it’s failing entirely and management and the team clearly don’t give a shit what you think.

The harder you try to insist on your approach the more credibility you will lose.

I also sense that your management probably doesn’t actually care that much about the outcome based on their actions.

So if no one cares and no one wants to change, I recommend the facilitation approach.

It’s human psychology.

Your job is to make people like you.

If you are likeable you will never get fired.

You think they actually care about the $1M outage.

They actually don’t care. It’s not their money it’s the companies money.

And management doesn’t seem to care.

So just be likable and facilitate and make the changes people are willing to make and remain likable.

Let go all of this opinion and ego about you installing all the perfect processes and refactoring the code base to be perfect.

It isn’t going to happen.

Give up on that.

Instead, facilitate the team to do what it is willing to do by providing options and walking them through and letting them agree to a course of action.

Give up on getting your way.z

And realize no one gives a shit about saving the company money.

They had an outage, they fixed it by hiring you. If they have another outage you can blame the team later lol.

It's obvious there wasn't just one outage.

If they'd rather quit than write some tests or have their code reviewed then that's a win for the company.

I'm sure plenty of engineers will take their place.

Also, notice how annoying this writing style is?

Where I put one sentence on each line?

This isn't LinkedIn.

And honestly, it's kind of ruined that platform, too.

The worst thing you can do is try to throw in 10 new best practices in 2 months.