Ask HN: New team with old members rejecting tech lead

Honestly it sounds like you just need to actually lead. Don't make proposals to the team, that is for management, you make the decision and you make it happen. It isn't a democracy. Now that doesn't mean you ignore concerns and feedback, but it does mean they need to get in line with the direction the business and team are going.

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.

I hate to say, but this is the correct answer. Implement the policies that you know work, do not ask for permission. They'll adapt and be better for it -- and I am saying this as someone that successfully implemented such policies in a similar situation.

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

This is a situation I'll be facing soon - a few years back the "parent" company decided to merge 10 separate tech departments into one - resulting in 10 different ways of doing something, 10 different release processes, 10 different branching strategies, etc.

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.

I proposed to fire/transfer some of them. Management was in favor but, after talking to them, decided to give them a chance to adapt to the new reality.

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.

With respect, I think your take on this particular matter sounds awful.

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?

Two months in the OP has destroyed whatever goodwill there was and lost the backing of management…I mean management talked to the “problematic” people and sided with them.

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.

My sense is that you probably could help them get their technical act together, if the team was otherwise in good shape, but that you're probably not the right person to provide the kind of comprehensive leadership they need.

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.

A lot of great suggestions here.

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.

It sounds like you are relatively new to being a tech lead, so I write this comment with that assumption.

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.

Their pride have probably been hurt. "Everything went fine for years and now after a few outages we suddenly get a babysitter".

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.

Looking from the perspective of 15 years of experience, I never took a tech lead role to lead established teams, it always appeared to me that in such teams there probably already is somebody who organically runs the team and I would be perceived as intruder. But I'm also not good when it comes to politics and people dynamics, and knowing my limitations I feel I can only run teams I build myself.. I'm most likely still not senior enough.

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.

15 whole years, waow

No one is willing to check your pr's? Jeez.

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.

You need the power to fire, hire, give raises, promotions, etc to meaningfully control a team in most cases.

If senior management undercuts you, move on.

Upset a functioning team then walk? That would almost certainly cause more damage than the team caused previously.

> They were skipping all the good software engineering basics.

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.

What were the reason for the outages? If it is directly caused by lax testing and deployment practices, then yes what you are proposing makes sense.

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.

Honestly, it sounds like you should cut and run. Maybe not now, but after the holidays. You're in the middle of poor management and worse sounding subordinates.

Yea good reminder that jobs like this exist when I feel like complaining, what an absolute shitshow

Don't throw it all at them at once. Work out a suitable order for bringing in certain approaches and then tackle it one change at a time. Start out with the changes that bring them noticeable benefits and you'll have a better chance of convincing them to adopt changes where they don't see the benefit to start with.

> They were skipping all the good software engineering basics.

Who decided the things you are pushing have anything to do with "good software engineering basics"?

Just because someone says it's cool thing to do, it doesn't mean it is, and it also doesn't mean it will produce good result in particular environment.

Look at it through Chesterton's fence - if team was able to produce good results without the "good software engineering basics", it may harm it. Thats' why you are rejected, and if I may - rightfully so.

I am too old to observe teams with amazing productivity - and any "good software engineering basics" would have destroyed it very quickly.

As a piece of advise - I would discuss with the TEAM first - what is their opinion about pending issues and how THEY would suggest to rectify it. Talk through suggestions, see what actually may help. Have them onboard instead of shoving off their face some smarty-pants management tactics you have read the other day in expensive book.

Guaranteed, if you put your ego aside, get to listen, and adopt solutions that solve actual problems instead of "code review (or whatever-cool-thing) is cool" - you will get on track very fast.

All the best

Have you read the post at all?

> 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.

What is your point may I ask?

If they were a high-performing team nobody would have brought someone external to steer the ship in the right direction.

The million dollar outage is probably a tall tail but passed around the management table as blame everyone can agree with because that group isn't represented.

You think "code reviews, tests, CI, and issue tracking" are just "things that someone said are cool to do"? Your argument is genuinely that these do not broadly fall under the umbrella of "good software engineering basics"?

Those items add overhead, are hard to add to some existing systems after the fact. Issue tracking is very important if you have someone creating the issues. A lot is going wrong here that some of the elements you suggest could help but by themselves probably not.

The problem here is classical - for someone with a hammer every issue looks like a nail.

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

That's a lot of new things in 2 months.

> Have I fallen into a trap?

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.

Is tech lead a formal position in your company?

Firstly, no one (including myself) is really going to be able to help you here without actually seeing how you and the team work. That said, I'll tell you what I think given what you're written here but please take it all with a grain of salt.

> 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.

Honestly,

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.

Wow I disagree with almost every line you wrote.

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.

He honestly sounded very experienced in this. If management doesn't care you shouldn't more than them to a point where you become a bigger problem. Take your 6 months grace time and listen to both sides. Try to boost your team's image to management by removing things that lead to negatives feeling (outages are caused by something, fix that something and put new process in place). Involve the team in the plan, create road map and go.

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