Working with arrogant perfectionist tech lead on another team

Question

I'm working on a large project that involves two teams: a software engineering team, and a devops team. The engineering team builds a product, and devops creates the infrastructure, build systems, automation, etc. needed to build and deploy our product. My team is about 5 times as large as the devops team. Al these teams have a mix of senior-to-junior engineers. We normally collaborate on all major design issues, but my team has final say and veto over all decisions.

Our company has decided to start taking on new projects in areas like cloud technologies such as Amazon AWS, Microsoft Azure, Google Cloud Platform, and a bunch of other cloud vendors. Plus, we're having to learn generative artificial inteligence, deep-learning, cloud computing, a lot of new things. This is requiring a lot of learning by my team, and the junior engineers are having a hard time keeping up. This is even harder given the size of my team. Still, we're designing a product that works with these new technologies, and it's working well.

Our devops lead, who comes from a privileged background, has the luxury of lots of spare time to study these new technologies or is already certified in them, and coach his team on them during his job and as overtime. He also does his team's work even though he should just be focusing on running the team. This is a team policy he somehow gets away with. Leaders are not supposed to code.

This artificially boosts the scores his team gets on efficiency, and affects raises and bonuses. He is now convincing senior leadership that my team's solutions are garbage, and that his solutions are much better. I think his solutions sometimes might be a bit better, but not always, and not as much as he brags. I am worried that if he keeps this up another team will be asked to replace mine. I've asked him to keep these discussions to leadership meetings, but if he doesn't get his way, he calls out "serious design flaws" during team meetings, and it affects morale. I have asked other devops leads in the company for advice, but they're all siding with his advice, and some of them are his friends, so I can't trust this advice. I've also tried arguing with him during his outbursts, but I'm not a living encyclopedia of all this technology. It's like arguing with a priest over the bible. It's just not a fair fight. And with his crazy overtime, its not realistic to compete, as most people will burnout working like that.

How can I fix this? Do I ask for budget to train my tech leads in this so they can prove him wrong, or maybe hire an outside consultant? This is making my team and me look really bad to my bosses.

Answer 1

Yeah... I don't think the answer you are going to get from me is the answer you want.

I read this twice and it sounds like a bad case of sour grapes.

Our devops lead, who, comes, from a privileged background, has the luxury of lots of spare time to study these new technologies or is already certified in them, and coach his team on them. He also does his teams work even though he should just be focusing on running the team. This is a team policy he somehow gets away with. Leaders are not supposed to code.

This paragraph in particular. I'm going to break it down:

'Has spare time to study these new technologies or is already certified in them'

Great - so it sounds like you have an SME in your organization who is competent in these new technologies.

'and coach his team on them.'

As all great leaders should.

'He also does his teams work even though he should just be focusing on running the team.'

So, he pitches in to help out his team get the work completed. It sounds like an awesome guy.

'Leaders are not supposed to code.'

This is a stupid as f... rule. I'll explain why in a moment.

'This artificially boosts the scores his team gets on efficiency, and affects raises and bonuses.'

And this is why I think this is sour grapes. It's all coming together now...

'that my teams solutions are garbage, and that his solutions are much better. I think his solutions sometimes might be a bit better,'

Really coming together like a well-executed plan.

I am worried that if he keeps this up another team will be asked to replace mine.

And there's the final nail in the coffin.

Now the actual answer time

You are jealous

I don't think this is a coworker problem; this is a you problem. You have a tech lead that taken the time to educate himself, on his own time, on certain technologies that your company is now wishing to leverage, he's upskilling his team, he is ensuring that his team are meeting their work requirements resulting in a financial and prestige bonus to him and his team.

And as a result, you are worried about getting replaced.

Now, the rule 'Leaders aren't meant to code'. I know of companies that have guidelines that management shouldn't do any frontline work as their primary focus is running the team, but an actual prohibition against it? If stuff is hitting the fan and you have a manager that is capable of helping, but instead refuses to pitch in with the team; I wouldn't call that person a leader. I'd probably use a number of 4 letter words.

The fact you would complain about this really did seal the deal for me that this is a you problem and not a workplace problem.

Now, it could be he's a braggart and an arrogant so-and-so and that his bark is worse than his bite, but the problem is that, as you acknowledge, his solutions are often superior and you don't have the expertise to say otherwise.

Your options are:

1: Get Good Scrub.

Upskill yourself. You can make all the excuses as to why he's done it and you haven't 'Oh, he's privileged, Oh he has all this free time to learn, Oh XYZ'. At the end of the day, no one cares. He's made the choices to upskill himself, so either you find the time and make it a priority in life or you can sit there and be salty about it.

2: Allow him to hoist himself on his own petard.

If he isn't as competent as he thinks he is, eventually he'll make a mistake, get egg on his face and that will be the time when you can suggest process and procedural changes to address what you perceive as the shortcomings (whether that's better PoCs, a dedicated development environment, closer alignment with best practices, etc.). And if he doesn't, he's either lucky or as good as he thinks he is.

3: Find another company that doesn't leverage these technologies and take the time to upskill yourself for when they (inevitably) do.

Answer 2

I have asked other devops leads in the company for advice, but they're all siding with him, and some of them are his friends, so I can't trust this advice.

Wait a minute. If some of the devops who are not his friends are giving you the same answers you need to take a step back and ask yourself why are you being so defensive. Are you trying to help the company be successful, or are you just trying to maintain the status quo on your team?

How can I fix this? Do I ask for budget to train my tech leads in this

If your company is committing to a bunch of new technologies then you should absolutely ask for a training budget to help bring them up to speed.

so they can prove him wrong,

Buzzt. Bad idea. Your team needs to be trained on the new technologies so they can contribute effectively to the company's new direction.

It really sounds like you're picking a fight with the other team lead because he threatens your ego. Don't do that. It's bad for you, bad for him, and bad for your company.

Answer 3

What a strange complaint this whole question is.

Our devops lead, who, comes, from a privileged background, has the luxury of lots of spare time to study these new technologies or is already certified in them, and coach his team on them.

The usual definition of "privilege" is either not having to work, or being extremely well-paid for one's work.

But I'm unclear how a man who is full-time employed, and who must be roughly your peer in both pay and responsibilities, can somehow have a surfeit of spare time which you don't have?

He also does his teams work even though he should just be focusing on running the team. This is a team policy he somehow gets away with. Leaders are not supposed to code.

In any kind of technical leadership at the forefront of new technologies, this would be an absurdity. If you don't spend some time using the technology, you wouldn't know how it works. You don't seem to be suggesting that he's neglecting his management responsibilities.

This artificially boosts the scores his team gets on efficiency, and affects raises and bonuses.

You mean he works harder and gets bigger pay?

It's like arguing with a priest over the bible. It's just not a fair fight.

Then why argue with a priest over the bible, if you already accept he knows far more about the bible than you?

Still, we're designing a product that works with this new technologies, and its working well. [...] This is making my team and me look really bad to my bosses.

Who thinks your product is working well? Your bosses, or you alone?

You don't inherently seem to be in competition with this other colleague. You are a software development lead and he is a dev-ops lead. Your outputs seem to be in two different areas.

---

How can I fix this?

1. If there are technical disagreements (in areas which are reasonably common concerns), then make time for working these out before you make decisions, rather than riding roughshod and then finding the conflict arrives in an unstructured way.

2. Heed the feedback you've had from a series of other dev-ops experts in your company, and avoid unnecessary and unreasonable resistance to ideas that even you acknowledge are often better than your own.

3. Ask your foe to provide some kind of structured explanation or tutorial on his preferred solutions. In larger companies, communication and training amongst a larger staff becomes a serious overhead, to be weighed against any advantage of novel approaches.

4. Set a reasonable pace. Or if you are being driven too fast by your own managers, then make the case that things need to slow down. Different teams may digest new technologies at different speeds, because there are a different number of implications and subtleties in each team's context.

Answer 4

I mostly agree with the other answers, but I want to provide you with a course of action.

I was in a slightly similar situation with a very good, experienced colleague with a very bad attitude (screaming at team-members, being arrogant, calling colleagues insulting names, being passive-aggressive, depicting colleague's work as his own, etc). His attitude eventually led (indirectly) to him leaving the project.

For me, it worked to separate the "hard-skills" and "soft-skills" part of the colleague and take my pride out of the equation: I learned from him some hard-skills / design approaches. At the same time, I gave active feedback for the (lack of) soft-skills, but also his excellent analytical skills.

To my surprise, he was very grateful for the open, grounded and direct feedback, because as he later confided in me he has trouble "reading" people.

One important note: I completely excluded "feelings" and never left anything to subjective opinion - when arguing or providing feedback I was very careful to be able to prove my statements and give examples, be rational and as objective as possible - this includes admitting when my own design/approach is inferior.

An excellent tool for grounded technical/architectural discussions and decisions are "Architectural Decision Records" - in order to make opinions more fact-based.

I suggest you take it as an opportunity to improve and grow.

Answer 5

Our devops lead, who, comes, from a privileged background, has the luxury of lots of spare time to study these new technologies or is already certified in them,

Your company only cares about results, not fairness. And you should feel the same way. It's usually better for your career to have colleagues that are top-notch that you can work with and learn from (even if they happen to be "from a privileged background").

he also does his teams work even though he should just be focusing on running the team. This is a team policy he somehow gets away with. Leaders are not supposed to code.

Sometimes leaders do code. And yes, for cross-training purposes, it's not good to depend on a single individual (with a bus factor of one), but if it's a question of getting things done or getting the architecture done right, you're going to lose this fight if you try using this argument.

How can I fix this? Do I ask for budget to train my tech leads in this so they can prove him wrong, or maybe hire an outside consultant?

Even with a training budget, it could take your team from 6 months to a year to catch up to this guy. Be realistic. Learning a technology takes time. And learning multiple technologies at once, that can take a lot of time.

Prove him wrong? If you don't have the expertise yet, how can you know for sure that he's wrong. And even if you do hire a consultant, chances are that this consultant will probably side with him. Usually, experts side with other experts.

Honestly, you should just let him take the lead. If that makes you look bad, so be it. But no one can be the smartest person in the room all the time. May be a year or two from now, you'll know more than he does. But until that happens, you should follow his recommendations. Don't fight it. The more you fight it, the worse it will make you look.

he calls out "serious design flaws" during team meetings, and it affects morale.

It doesn't have to. Just include him in the design decisions from the very beginning. Some of the best leaders I know are the last to speak in a meeting. Become that kind of leader.

Schedule a private one-on-one meeting with him. Stop arguing with him. Start treating him like a mentor. If you have concerns about redoing some of the work your team has already done, voice them, but don't fight him on the larger picture.

Answer 6

I am going to take a slightly different tack from the other answers, with which I already tend to agree, to talk about dev-team staffing concerns:

My team is about 5 times as large as the devops team.

Hes trying to prove he can automate my entire team for s***s and giggles.

"serious design flaws" during team meetings, and it affects morale

So, you have a biggish team that is not as up to speed as the devops team in the core relevant tech, whatever it is.

Now, I am going to completely ignore for a second schedule constraints, but here's some thoughts:

• Slim down your part of the team that codes and designs, to your best people. Put the others into holding mode (hey, maybe train them)

• Have your best folks engage with him and his team to thrash out a better approach and what they can teach you. Maybe he's wrong. Quite possibly, as a devops guy, he's only seeing the tip of the dev iceberg. Also quite likely, as a devops guy, him and his folk don't want your job because they prefer theirs.

• Once you've corrected your design flaws - or not, if they weren't really flaws - and once you have identified a good reproducible approach, bring back your more junior people, once they have a solid design and approach to work with.

Now, you don't have to really put everyone on hold. But it seems to me you shouldn't be engaging in "problem definition and approach determination", i.e. proof of concept, with a team that is 5x the size of the other team, using juniors with low qualifications in the relevant technologies. If that is an unfair assessment on my end, does that mean the "serious flaws in design" were not?

Maybe keep most of your team going as is, but task your best people to figure out what can be learned from him, as a side project? Maybe that is not much, due to pesky non-devops considerations like customers? In which case you've answered your question. Maybe that is that your team is too bloated and ill-prepared?

But it sounds to me like you are operating on shaky technical grounds, feel defensive about it and are all too ready to shoot the messenger.

Long term, the best service you can do for your people is to make them more skilled. If there is indeed an approach to make them more productive, don't waste it. If your team of say 20 can do better work with 10, then that makes those 10 more valuable on the job market. What about the other 10? Well, I notice you talk about other devops= teams which implies other dev teams. In my experience, competent extra technical people mostly just get provided as resources to other teams, so your "but they'll be laid-off" rationale seems questionable. Past the initial discovery phase, once you stabilize with a perhaps smaller team, don't keep just your senior superstars. Cycle in some of your promising juniors.

I've upvoted the question btw. The fact that I think your approach and attitude is wrong does not make it a bad question. Quite the opposite. There are certainly times I might have asked a question, gotten an uncomfortable earful in answers and adjusted my actions for the better.

p.s. If you have valid reasons to feel he could be more diplomatic in public, this is certainly something you can ask him to do, especially once you've established that you're open to change yourself. There is no reason your team needs to put up with abusive discourse, if that was indeed the case.

Answer 7

Is it possible that this is really about AI?

Based on this comment, the core issue seems to actually be a fear of having your team be wrongly replaced by a combination of AI and a subset of his team:

"He demonstrated how he thinks he can replace most of my team with just a few people from his team and some AI tools he wrote."

Is he right?

Is he right? From what I’ve seen from generative AI there’s no way it could replace all but the most unskilled developers (and really not even them), but I also know it’s changing daily. Is he right or is he just jumping on the hype train and you’re understandably worried the higher ups will listen, fire your team, and only later realize they made a mistake? If he is right, you need to do some soul searching. But if he’s not right and you want to prevent company leadership from making a costly mistake…

Lean into AI

A really good idea here is to embrace generative AI in your dev work for real—really lean in and stretch it to its breaking point in all aspects of dev work. Treat it like applied research.

Use existing tools, products, and services, and where appropriate even create your own. Importantly though make sure to also use your colleague’s tools. Today. Immediately. Track their performance, their strengths, their limitations. Know them inside and out. Make sure you always have the current version. Document everything. Knowledge share often in ways that are traceable and as public as is appropriate, ideally with visibility from the managers who will be deciding the fate of your team. This is very important. By essentially adopting a variation of your colleague’s proposal as an experiment, you either undercut them if they’re lying and just trying to get ahead at everyone else’ expense, or you make your team stronger and enable them to do more with less, delivering more value (a win for the company), keeping their jobs (a win for your team), and helping your colleague’s team by helping them improve their tools with targeted feedback on gaps and suggestions for improvement.

In doing all this you'll also likely find some useful tools for your team (at least for some use cases), you’ll know much better what works well and what doesn’t and how to responsibly use AI in dev, you’ll have developed in demand skills in yourself and your team.

And you’ll now have actual data to bring discussions about the future of your team, e.g. “that’s really interesting John. In our use cases while we found that using your team’s tools did yield a 10% performance boost, we found having an expert human in the loop to be very important. Without that defects would have tripled, resulting in human rework which would ultimately result in a net 20% performance reduction.”

Bottom line:

Make yourself the expert on use of AI tools in dev on your team so that when discussions about the future of your team happen, you're now the expert with hard data and your colleague is the one speculating outside of his expertise. And in doing so you will help your company and your team. Win-win.

Answer 8

At a previous job, I was that "arrogant perfectionist tech lead". I knew the company's main product better than the original people who developed it. I also totally get the "privileged background". I could study different technologies our company wasn't using to see if it could solve problems that didn't exist yet for a few hours a day, still get all my work done plus other improvements not in the formal "to do" list, and attend extra meetings that changed the direction of the company.

My biggest problem though was being able to communicate why my ideas were better. Whenever I told people I thought it should be done one way instead of another and they chose not to follow my "advice" it caused problems either for me or the company later down the road. Not to say I didn't make mistakes either, but life was generally better (for me at least) when things went my way.

Eventually my boss came to me and said a coworker had complained about some changes I had made to their code. He said I should try to explain the reasons behind the changes to the coworker before making them. I tried following his advice and when I started explaining my changes my relationship with that coworker improved to the point where I started going to him for advice and he to me. He became an asset to me instead of an annoyance.

I mostly wanted to give the perspective from the other side. I still have tons of things I need to work on. However, as others have mentioned, communication and trying to understand the other person will make things much easier and improve (upskill?) everyone involved. Within the company, it is a co-op game. Not a competition.

Answer 9

This question definitely has some AI undercurrents, but I think that, more generally, it is about the nature of software development.

Here's the thing: any software developer worth their salt, is pretty much constantly engaged in automating their own job. This is one of the unique challenges of software engineering, and also what makes this profession interesting in the first place. If you ever find yourself in a daily routine where you can pretty much describe your daily activities in an algorithm, your duty as a good software engineer is to code that algorithm into a little script, and tell your boss that all further assignments of the same nature should be directed to that script. I've done this dozens of times during my career, and the response never was, "So, Mr. R., looks like we don't need you any more. Why don't you go pick up your last paycheck and have a good day!" You just have to trust that there is more work to do, and there always is. Your company is already working on the next big thing where, hopefully, you can pull the same trick again.

It looks like your colleagues in DevOps already have internalized this mindset. After all, their entire mission is to automate development processes, and they probably have a keen eye for repetitive and tedious tasks that are ripe for automation. Automating the creation of software itself is nothing new and has been done for decades. Some of the most complex pieces of software (e.g., compilers) haven't been written "by hand" in a long time. More recently, we have domain specific languages (DSLs) and tools like Simulink that create code in a few seconds that would take a developer days to tap out. And now, of course, AI.

I suspect, that when you take a step back and analyze what your own team is doing, you will find that a good portion of your developers is engaged in some kind of busywork that boils down to data entry at a slightly higher level. In other words, they take some kind of input documents or instructions (restaurant menus, tax forms, product descriptions, data models from partner companies, etc.; I don't know what business you're in) and translate them to code, according to some written or implicitly understood rules. You didn't see this as an opportunity for automation, and now your colleague from DevOps stepped in and pointed it out.

AI has made it possible for things to be automated that were difficult to automate before. But even in the age of AI, the creative, analytical, and problem-solving aspects of software engineering are difficult if not impossible to replace. If you are a true software engineer, you never have to worry about being replaced by AI, but you will definitely use AI more often during your quest of automating your own job.

It sounds like you've created an adversarial relationship between DevOps and your own team. That's usually never a good situation. The DevOps lead is your coworker, so treat him like one. Ask him how your team can contribute to his vision, and he will probably have some ideas to keep your team busy for a long time.