20

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.

4
  • 1
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – Kilisi
    Dec 28, 2023 at 20:21
  • Something’s not clear: is your team now competing with your colleague’s team? It sounds like your team has veered into devops work which is your colleague’s wheelhouse and lane and it’s not going well. Is this correct, or did I misinterpret your question?
    – bob
    Dec 29, 2023 at 2:12
  • 5
    Actually based on a comment you made below, is the core here about your colleague claiming they can replace your team with some AI tools and a few of their own people? If so check out my answer, and you probably need to edit your question significantly to make this clear. That’s not at all obvious as written.
    – bob
    Dec 29, 2023 at 4:05
  • "He is now convincing senior leadership that my team's solutions are garbage, and that his solutions are much better." Echoing @bob 's comments, are these solutions to the same problems? Or is he saying that his solutions to dev problems are better than your solutions to eng problems? Dec 30, 2023 at 2:10

9 Answers 9

95

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.

14
  • 28
    I suggest replacing the juvenile gamer trash talk stuff with more professional language. Otherwise a solid answer.
    – barbecue
    Dec 27, 2023 at 12:58
  • 27
    So don't jump jobs; take advantage of the learning opportunity instead.
    – keshlam
    Dec 27, 2023 at 15:38
  • 25
    I believe the proper spelling is "git gud" Dec 27, 2023 at 21:06
  • 42
    There's another option: At my company, whenever a lead on another team has expertise I do not have, I drag that person into private high level discussions about what we're planning to do, so that way he can correct me privately. Then, in my plans, I put that person's name right after mine at the top, and also in the acknowledgements at the end, and give them a verbal shout out for their expertise. And then throughout my work, if I'm unsure, I send it to them privately for double-checking. I also make sure their manager knows they're awesome. USE THEIR KNOWLEDGE to make your work better. Dec 28, 2023 at 16:18
  • 19
    @ampreetsolaire Did you just choose to not read the parts where Mooing Duck said to give credit? Not really right of you to say that he needs to get things his way on his terms when you do that. Keep your enemies closer.
    – DKNguyen
    Dec 28, 2023 at 21:06
64

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.

10
  • 1
    I have a budget to train team members, but even with a massive budget, we can't train an army of expert-level cloud engineers overnight, or even in 6 months. Dec 27, 2023 at 4:10
  • 26
    @ampreetsolaire then why are you focused on 'proving him wrong' when you admit that he is at least sometimes right? Why are you rejecting the answer of the other devops engineers who aren't biased because they're his friends? Dec 27, 2023 at 4:13
  • 19
    Pointing out a serious design flaw is not an attack per se, it all depends on how it is brought up. Is he critisising designs or people?
    – Helena
    Dec 27, 2023 at 8:25
  • 16
    There may be better ways to phrase the critiques. If you focus on that, there are reasonable answers. But you seem to think that all criticism is damaging, and it shouldn't be.
    – keshlam
    Dec 27, 2023 at 15:40
  • 22
    @ampreetsolaire He actually provided examples of things that are wrong rather than just saying everything is. Your words make it almost sound like you think that wrong things should be ignored just because feelings will be hurt. That is obviously bad but seems to not have occurred to you. You seem too focused on your own position to be aware of that a lot of the things you are saying do not look good. You need to look at this from the other side of the table and read what you are really writing. You can't fix this situation while thinking like that because it will just make you the villain.
    – DKNguyen
    Dec 28, 2023 at 15:55
20

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.

10
  • 17
    @ampreetsolaire, you seem to be defecting from some of your main responsibilities - to control the circumstances of your own team, and to be able to handle technical arguments - whilst engaging in a competitive feud with someone whose role ought to be complementary with yours. I don't fully understand how him looking good makes you look bad, because however quickly he works, he's ostensibly doing a different job than yours. Is the root of the problem possibly that your own managers have created an environment in which your employment doesn't feel secure?
    – Steve
    Dec 27, 2023 at 16:24
  • 15
    @ampreetsolaire, if a smaller number of people with machinery can fully do what your team does, then they inevitably will - that's the whole point of computerisation, to mechanise routine activity and leverage a smaller number of managers who configure and oversee the machinery (rather than overseeing waged staff). If you spend all your time hassling other managers and opposing labour-saving applications of machinery which might make part of your human team redundant, you're more likely to undermine all your value and precipitate your own redundancy first of all.
    – Steve
    Dec 27, 2023 at 20:16
  • 13
    "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." - give it 3 years and there is only one team - the smaller one - and in 5 years it is all project managers. You bark up the wrong tree - you are just behind the technology curve. if it is so easy to replace you NOW with AI - he either lies or... he is right. Bad news if he is right. For you.
    – TomTom
    Dec 27, 2023 at 21:06
  • 8
    If the reasonable fear of AI replacing your team is the core issue you need to edit your question to make that clear. Right now this is not at all obvious.
    – bob
    Dec 29, 2023 at 3:00
  • 6
    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 worried the higher ups will listen, fire your team, and only later realize they made a mistake? A really good gambit here is to embrace generative AI in your dev work for real—really lean in and stretch it to its breaking point in dev work. You’ll likely find some useful tools (at least for some use cases) and you’ll have actual data to bring to…
    – bob
    Dec 29, 2023 at 3:02
17

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.

4
  • 2
    I like this answer because it is trying to objectively address OP's concerns rather than spending effort building a fairytale about how OP is wrong. Dec 29, 2023 at 3:05
  • 4
    @displayName, Except, the guy in question only said that OP's plan had "serious design flaws". That's not screaming. That's not making it personal. That's not passive aggressive. That's not taking credit for someone else's work. And honestly, if he has more experience/expertise on this matter, that's not even being arrogant. Dec 29, 2023 at 6:57
  • 2
    @StephanBranczyk: Maybe, but… “Serious design flaws” can be pointed out to in many ways, including gently, rudely and even in passive aggressive manner. We can’t deduce the tone from the text. Secondly, he may not be taking credit but he may be hindering the progress by misusing his expertise rather than using it constructively for betterment of not just his team, but larger organization. Dec 29, 2023 at 12:24
  • 2
    @StephanBranczyk there is no attitude being described in the phrase "serious design flaws", as displayName said. This expert (which we all have agreed is a real expert) might have been a cunning person at office politics, for example, which is really trying to undermine OP's team (for good or for worse). But that said, I agree that there are lots of good things that OP can learn here, especially from this answer, to separate the hard skill and the soft skill.
    – justhalf
    Dec 29, 2023 at 15:12
10

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.

5
  • 14
    "he calls out "serious design flaws" during team meetings, and it affects morale" - well, here is something nasty to add. If they ARE serious design flaws, then morale SHOULD suffer. Of those people that did bad decisions. The low morale leading to "damn, i should get competent".
    – TomTom
    Dec 27, 2023 at 21:07
  • At one point I would ping this person for help. He wanted to propose an improvement himself rather than let me present it, even though he would get his way for the technical decision. He needs to win every argument and take 100% credit for anything he touches, or he won't help. I cant have this person leading meetings and possibly throwing me undr the bus. Dec 28, 2023 at 4:31
  • 12
    @ampreetsolaire, Honestly, if it's his expertise you rely on, you should publicly give him the credit yourself. You need to read the handwriting on the wall, this guy will either become your boss some day, or he's going to be poached by a competitor and will get a promotion that way. When you find someone like that, you help them rise through the ranks of your company. Dec 28, 2023 at 8:25
  • 2
    @TomTom No. Everyone makes bad decisions. A good company process identifies and mitigates the effect of those decisions early, and turns them into better ones.. If "We'll make you feel bad when you make a mistake" is a policy, then good luck retaining people with better employment options.
    – Player One
    Dec 29, 2023 at 9:51
  • 5
    If you have made a mistake you should feel bad. Briefly. Then you should fix it, and feel good about having fixed it and learned from it. "Development is the art of debugging a blank sheet of paper." Most developers -- and managers --have more than enough self confidence to accept that. It sounds like you are taking "protecting your people" to an entirely unjustifiable extreme. And it sounds like this is much more about your own reaction than theirs. The guy is trying to help you all be better. Swallow your own arrogance and take advantage of that.
    – keshlam
    Dec 29, 2023 at 14:37
7

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.

2
  • For "more diplomatic in public", In another coment i said that I tried this. But he stopped cooperating after I agreed with an idea of his but didn't give him credit. Now he makes sure that this kind of thing is discussed publicly instead of privately so he gets all the credit. Needs to get things his way, and on his terms. Dec 28, 2023 at 21:06
  • 10
    “after I agreed with an idea of his but didn't give him credit. Now he makes sure that this kind of thing is discussed publicly instead of privately so he gets all the credit.“ You admit that you’ve tried to steal the credit for things he’s done, and yet it’s his fault for ensuring you can’t do it again? Dec 29, 2023 at 1:25
5

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.

5

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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .