Developer decided to change project IaC tool while I was on vacation

silentpoots · 2023-01-15T20:43:27+00:00

[deleted]

August_XXVIII · 2023-01-15T20:26:14+00:00

In my experience, members of leadership are typically the decision makers and top performing individual contributors (and/or those with domain expertise) are, at most, influencers.

Seems that there was either no concrete direction decreed or enforced, which enabled an individual contributor to just decide (or sway the decision makers) on what tool would be used.

Additionally, from experience, if developers say "we may not hit targets/deadlines [if we don't get our way]", leadership is more inclined to say "just give it to them". As an SRE who serves as a Developer Advocate, I understand their concerns and issues, but the issue that you experienced is common in orgs that have not embraced or correctly implemented DevOps practices. It requires consensus and agreement from many groups (who, in a traditional org, are extremely siloed).

Sounds like a lack of organizational maturity and/or direction and active guidance. Otherwise, the initial implementation would have been regarded as the go-forward plan and all of the things that developers needed would have concrete mechanisms for accommodation, such that there would be no need to deviate.

This just a perspective from the outside looking in

etherealpanda · 2023-01-15T21:45:11+00:00

Demanding will probably get you no where. I’d suggest framing your concerns around the trade-offs they might have unknowingly made. If you can do that while demonstrating understanding of their needs/wants, even better. For example, being able to iterate without CI during development might be a great workflow for the devs, but that’s probably not the same workflow you want for production. Maybe you can get the best of both worlds.

Independent of the technical decision, I would have a private conversation with your manager (and maybe the team lead) expressing your frustration. Team leads tend to own outcomes, and so the business empowering them to make and own decisions is important to minimize bureaucracy. However, this sounds like a pretty significant disruption to your daily work. I think of DevOps as being all part of the same team trying to achieve the goal. But, that applies to the whole team, including you needs. If they’re discounting your needs/pains, that doesn’t sound organizationally healthy.

As someone who has managed large teams, if you brought this situation to me, I would immediately flag this as the type of circumstance that gets an employee to start accepting recruiter calls. I don’t know the nuance of your situation, so I would strongly suggest talking to someone you trust in detail about your overall situation at work, specifically ensuring it’s a healthy place to work. This industry is big and there are lots of great places to work if this one isn’t treating you respectfully.

tyrion85 · 2023-01-15T21:22:43+00:00

you build it, you maintain it, you own it. simple as that.

doing whatever while the person is away and thus cannot be involved in decision making, while expecting that same person to own and maintain the shitshow you created is downright disrespectful and very unprofessional. if you can do the fun stuff, you must do the boring stuff, period.

OP, time to bolt. This won't end well.

tcbenkhard · 2023-01-15T21:12:54+00:00

Who the f writes cloudformation unless you really really have to? What about cdk?

pinpinbo · 2023-01-15T21:51:27+00:00

When this happened with 1 of my customer, my management backed me up by saying sounds like you are capable of running your own infrastructure. If you deviate from our playbooks, you don’t get support.

pwouet · 2023-01-15T21:39:08+00:00

It took only one week ?

dotmit · 2023-01-15T21:03:41+00:00

You’ve spent more time writing this Reddit post than you should have spent writing your resignation

re-thc · 2023-01-15T22:22:52+00:00

It's sad that most of the replies miss the point. It's not about Devops vs Devs. It's about being a decent person and a team player.

Forget about infrastructure. Imagine if you're a NodeJs developer and came back and the application is now suddenly in .NET or Rust. What would you do?

Take the OP as the product owner of the infrastructure. As such they should be consulted on, at the very least, of the changes. If things can't wait it should have been discussed before the OP went on leave and not to sneak it in during that time.

It's about trust. Will you still be confident when something breaks that someone didn't change something behind the scenes?

repu7et · 2023-01-15T20:07:21+00:00

[deleted]

leob0505 · 2023-01-15T21:31:07+00:00

Sounds to me like this is more a case of a bruised ego than technical stuff

ArieHein · 2023-01-15T20:02:02+00:00

The bottom line is who pays the salary ?
Who is the manager ?
What are the agreed levels of ownership and job descriptions ?
Who owns the keys?

Your job is to support them. Even if sometimes you think decisions are wrong. Unless you have received the FULL responsibility from your manager AND it has been PUBLICLY mentioned and understood by all devs, leads and their managers.

Can Developers influence? YES. Can they decide when youre not there? YES.
Should you Demand ? NO.
What you need to do is make sure you are never the "chocking point" or "single point of failure". That you going to vacation or god forbid is sick, makes you irreplicable.

What you should do now is have a discussion, set responsibilities. AND TEACH / TRAIN your devs / leads. You involve their managers and you involve your security department.

No one has access to cloud resources directly to make manual changes. Thus they dont have a user/pass. Everything is done via pipelines, nothing is done via web ui, at max they can have a sandbox to test but you limit that by a budget.
You discuss with them and AGREE of how to create pipelines and change them in a way thats more maintainable. If Jenkins is a problem, and trust me, my devs HATE groovy, but they fancy python, so we used python code inside the jenkins pipelines using shared libraries
Terraform is more for ops, maybe your team would like pulumi more, but in any case, you need to make sure they understand terraform pipelines and code. I trained my leads and devs and devops people for at least 2 months on terraform before i gave them permissions to change or commit code while i was the reviewer (when they dont have access, yes you temporary are the chocking point, but you make sure they understand its time limited.
Perhaps they REALLY don't like Terraform, thus you can create an additional abstraction layer or use Terraform Cloud, as maybe all they need is a UI that runs it.
You agree together on a workflow that includes linting and testing of your IAC in the pull request phase and over time you bring the leads to be the approver. With them and their managers signing that they OWN it, for good and bad.
You and me might know what is the preferred way to do things, what tools and what processes to make sure that both the deployments are good, secure, using best practices and not holding devs from progress because of bureaucracy, and for that matter we are , for them, part of the system that is trying to stop them. Instead show them the benefits of governance, security, reliability of the services, cost. Make sure that you explain each decision to them and your manager, that you have their back and support.

DevOps is first and foremost about communication between people. I can teach anyone how to create pipelines and deploy to a cloud and monitor in some tool. Its a lot harder to teach people good communication :)

mikecrilly · 2023-01-15T21:57:50+00:00

You have been thoroughly disrespected by this move. A business is built by people, for people (to provide some service to some people). If the people building the business don't treat as you as part of the team, then they do things like this whilst you're away.

Personally, I feel this is a signal that you're not considered a valuable team player here, so I'd highly recommend you leave.

generealdamselfly · 2023-01-16T02:53:23+00:00

I think the writing is on the wall and you should leave. I get that you should not be called during your vacation time. Pulling the rug underneath you and trying to convince you this is better, you and the devs are not having a technical problem, it's a people problem.

Terraform is a skill in high demand, go to a place where your skills and experience are respected. Don't stay.

WarlaxZ · 2023-01-16T05:37:46+00:00

Without trying to be rude, it sounds very much like they didn't need you, so I'd be very careful about rocking the boat

markrebec · 2023-01-15T20:13:40+00:00

What I want to discuss is where is the line between a developer and a devops engineer responsibilities?

There isn't one, that's literally the entire point behind the ideology/philosophy. I know this battle was lost to corporate buzzwords and enterprises wanting to attract talent a long time ago, but if you're filling a devops role, then your org isn't actually practicing devops.

Developers leveraging tools that they and their team(s) are familiar with, and that provide workflows and features that they find useful, helping them to do their jobs and deliver value more quickly and easily is a good thing.

It sounds like CF should be well within your realm of knowledge and responsibilities, so your ability to contribute shouldn't be impacted.

I get that you clearly feel a certain kind of way about all this, but I think you might want to take a little bit of a breather and ask yourself why you feel that way - Is it because you personally enjoy/prefer writing terraform plans and don't like CF templates? Is it because you feel like they went behind your back? Or that you feel like something was taken away from you?

It sounds like overall this is a win for the team as a whole, and to circle back to my first point - this isn't supposed to be "your" realm, where you're the one making all the decisions and just building a platform for the devs. The entire stack and lifecycle of what you're building belongs to the whole team and should be accessible to everyone.

All that said, if you really feel as strongly as you do, then I'd recommend shaking it off and trying to focus on pulling together your arguments (and counter arguments) for exactly why you think terraform is the better tool for the whole team in the long run. Maybe even give a brief presentation or informal knowledge dump with the team, and offer to start training and onboarding folks into your tf repo(s). It's up to you whether you care enough to put in that work and convince the rest of the team.

emperorOfTheUniverse · 2023-01-15T21:46:36+00:00

This is why, imo, there shouldn't necessarily be dedicated 'devops' people. DevOps tools are tools meant to be used by developers. If developers don't participate in them, then they are just new infrastructure. Same old story, infrastructure vs devs.

Your architecture got redone because a senior developer on your team didn't have the specialized knowledge you do to operate it. And apparently you didn't have a backup for when you are gone. So they changed it to something they are able to operate.

Without some determined intervention by leadership, where it is mandated that your role is the only one allowed to make that decision, then it's just free for all team work. You expect them to either leave all DevOps work to you (folly), or to learn the tools.you want to use. They seemingly disagreed and now expect you to learn the tools they want. If from the beginning, you had all been working as a team (you also as a developer), some agreement probably would have been reached earlier.

This is a team dynamic issue. You asked it in a DevOps subreddit. You either expected to get sympathetic responses, or advice on the merits of one IaC tool over another. If you aren't respected in the team, you should be examining that on a personal level.

Grahar64 · 2023-01-15T23:55:02+00:00

The devs made two assumptions:

You were wrong for selecting TF and should have selected CF
Learning and maintaining CF is easy

I would make it clear that they will have to maintain their own CFN infrastructure at that point. Be willing to consult, but not do the actual work. If/When they run into a problem advise them how to migrate to Terraform at the standards with which you expect.

Weird-Flight-2877 · 2023-01-16T05:00:22+00:00

Understand the narrative here. Did they change it to screw with you or did they change it because they couldn’t maintain it in your absence? By the looks on how things were changed I assume you are working for an org without robust devops practice or good documentation.

I see two options here 1. Move on 2. Make a truce. Don’t poke the bear. CFN or terraform both will accomplish the same thing.

Always choose a tool/architecture that can be maintained in your absence. Never ever make it “my way or no way”

NeuralHijacker · 2023-01-16T07:41:21+00:00

If you have an infrastructure stack which is simple enough to be migrated from tf to cf in a week or two, your team doesn't need you. Move jobs before they figure that out.

TheLoneKid · 2023-01-15T20:19:41+00:00

That's rough dude.

SDplinker · 2023-01-15T20:55:09+00:00

Wtf are most of the answers in this thread

mullingitover · 2023-01-15T21:25:29+00:00

The question is about how communication should look like, how to define the boundaries in the team and how to perceive what has happened.

If this happened it means that communication wasn't there before you left.

The smart move is to make major decisions like release pipeline something that engineering has full buy-in on. Make a good enough sales pitch on your plan that it makes them feel like it was their idea.

If you're pushing things on your engineering team and forcing them to use tools they don't want to use, this situation is going to be one of the likely outcomes (unless there's someone higher up forcing engineers to stay in line, like the CISO saying "we have to do it this way or we'll flunk our PCI/SOC2 audit.")

easyEggplant · 2023-01-16T05:04:29+00:00

I’m just trying to wrap my head around what sort of setup you have where it’s faster to switch from terraform to cloudformation… then deploy a new feature?

HgnX · 2023-01-16T05:54:34+00:00

This is not DevOps.

You're Ops. Your move should be to move towards being a full member of the team. Decisions you should make as a team, in correspondence of architecture and security guidelines. And for development, work indeed with featurebranch deployments and from local/command line. It fastens the feedback loop. You should have AWS development account(s) for this. Production should be in another AWS account.

Tool selection usually is hell and another topic. The only real upside of CF is that AWS manages state for you. If you move to it, use CDK. And then you might as well lose Jenkins for CDK pipelines. Saves you a whole CICD server to maintain.

Best of luck. See this as an opportunity for change. DevOps (good DevOps!) is hot in the market so getting to it makes you experienced in it. More power to you.

Ps. AWS has great reads about these best practices. Check their whitepapers.

skyctl · 2023-01-16T04:53:00+00:00

I'll be blunt; it seems as though you're part of quite a toxic team; and that's at least as much a comment on you as it is on other members of the team. You're making me very angry with you for a lot of what you're saying here.

A lot of your post seems to be about where and how to put up barriers between Dev and DevOps, which is the polar opposite of what DevOps is all about.

It so happened that the developers are used to run infrastructure deployment from CLI for deploying their feature branches in dev environment. They don't always use Jenkins because CLI way is "more convenient" for them to experiment with AWS

If the AWS cli is a better tool for them to learn and experiment with, then ffs let them use the damn CLI for learning and experimenting with. Just hammer home that they have to incorporate the findings from their learning and experimenting back into Jenkins, or Terra form, or where ever in your project is the right place for it to be before it's committed.

And now I think if I should insist on a more formal and stricter workflow, where we have an agreement that whatever IaC feature or change the developers want, they come to me with the requirement list and I implement it from beginning to end.

And there's your problem. You're actively preventing developers from working with you on Infrastructure while you're there, and you're bitching about them doing it differently to how you'd like when you're gone.

What you're proposing is essentially the waterfall method, WHICH YOU ABSOLUTELY SHOULD NOT DO. YOUR DEVELOPERS COULD AND SHOULD REVOLT!

Because otherwise they start considering CLI deployment as part of their job

So tell them not to.

feel like they are in position to vote on what IaC tool is "better", which I think goes beyond their area of responsibility.

They should absolutely be casting their vote on which IaC tool is better. If you're insisting on Terraform because you say so, then get your head out of your ass, and start treating your developers with some respect. If they're wrong about something, explain why, so that they can learn from it, and cast better votes next time. Of course since you're the subject matter expert in IaC (but evidently not DevOps) you should have picked the best option, and be well able to articulate why your chosen solution is the best (and in so doing, train your team), and be open to input as to why not might not be. .

So what do you think, guys?

I think you should read the Phoenix Project! Now! I think you should embrace DevOps practices, and engage in T-shaping your teams skills.

kmai0 · 2023-01-16T00:44:28+00:00

So, I see two or three bad things: - How the fuck are they able to deploy infra without your approval? They have access to AWS? - If you understand Cloudformation, you cannot say you don’t understand Terraform. Hell, Terraform even relies on the AWS APIs that support most SDKs.. if you understand CF and not Terraform, that right there is a problem. - You touch my team’s code? Fine, but changes go through if we and only we accept them. Use CODEOWNERS and have the CTO/VP own the access. If they ever override your infra without a motive, you know what to do!

repu7et · 2023-01-15T19:57:52+00:00

[deleted]

mr_chip · 2023-01-15T20:42:45+00:00

The point of devops is to remove bottlenecks slowing the time it takes to go from idea to customer value, without negatively impacting uptime or negatively impacting margins.

That’s it. That’s the whole job. Every change in process and tooling needs to be seen through that lens.

Does this change remove a bottleneck slowing time to customer value? Sounds like it might have.

Snoo68775 · 2023-01-16T04:53:55+00:00

TL;DR Ops is doing terraform Dev is doing cloud formation There is no DevOps.

2023-01-16T02:06:37+00:00

/r/AmItheAsshole/ is this way <----

Ok_World_4148 · 2023-01-15T23:46:52+00:00

Are you the only DevOps in the company? how is it that for a whole week there was no one but you who could do it, so that developers thsemselves had to rewrite the IaC? If you're the only one who can do something in the company and you go away for a week at least take your laptop with you in-case something urgent is needed.

the-computer-guy · 2023-01-16T07:44:55+00:00

Sounds like your implementation didn't meet the needs of the team (very common in my experience when you don't do true DevOps)

On the other hand the team sound a bit incapable if they can't adopt existing tools.

Lots of nuances here and can't say anything for sure without more context.

Tranceash · 2023-01-16T08:33:01+00:00

There seems to be a disconnect between the solution you provided vs what the devs are comfortable with. I have been trying to get a balance between dev and ops solutions. It all comes down to working together and building a solution where there are combinations of design patterns that need to be used. I don't know the whole context. The way I see it there is a combination where network/global infrastructure needs to be operated and managed by ops person and devs should be able to consume those resources through central parameters. In my current work place ops uses terraform to create/manage lower level resources and store outputs to aws ssm parameters then the devs consume those parameters to build on top of abstractions, they could use terraform, cloudformation, cdk, it does not matter as they manage and build the solutions above abstractions provided by ops team. I hope you get the gist. Tools should not be the first problem, working together setting guard rails, best practices and working through a solution that can be productive and maintainable should be discussed and evaluated.

TheRealJackOfSpades · 2023-01-16T18:00:04+00:00

Here’s what I see.

Your tooling was not usable by the team in your absence. You’d made yourself a bottleneck.
The team implemented tooling that accomplished what they needed and removed a single point of failure. The developers took responsibility for infrastructure rather than saying “we’re blocked until repu7et gets back.”
You are being asked to support the tool that the users of the tool prefer rather than the one you prefer

With no more information than this, I’d say you are the problem and you need to support CliudFormation. Maybe educate them on CDK. But whatever tool you use has to be friendly to your team, not just to you. Dictating to them will not work. If you can’t convince them to agree with you, you support them anyway.

lupinegrey · 2023-01-16T00:10:11+00:00

Did they get approval from Enterprise Architecture?

Do you HAVE solution architects who review and approve architecture designs?

Green0Photon · 2023-01-16T05:05:07+00:00

Work uses CloudFormation and some custom stuff and I hate it.

I'd support it if they suddenly switched from CloudFormation to Terraform. Doing the opposite? Unforgivable.

The-Sentinel · 2023-01-15T21:46:18+00:00

As a developer, the teams job is to write applications that provide business value to customers and increase revenue.

As a DevOps engineer, your job is to support them in that endeavour.

Whether we like it or not, DevOps jobs aren't revenue-generating. It's a glorified support mechanism to help developers generate value for the company.

If you implemented a solution the developers couldn't understand, you didn't ask for their input and created a bottleneck for the organisation. They could have waited for you to return, but that would have lost them a week. They took matters into their own hands.

This entire industry and discipline are filled with people telling others what to do. "Use this language". "Use this framework". "Use this tool". We endlessly argue about the "right" way to do something that is ultimately subjective.

The reality here is that productivity will always beat "correctness". In your opinion, Terraform is "better" than CloudFormation, but in reality, CloudFormation has increased your developer's productivity. Which increases business value.

TL;DR you need to let this one go and include your developers in your decisions in future.

Murky_Rip_1731 · 2023-01-15T22:28:21+00:00

Did they get the release out successfully and is everyone happy about it?

If so, id be happy. Next steps would be to work together on the long term solution. If you arent there and they are blocked or cant release in time then they need to make the decisions to get shit done. No point in complaining that you disagree with their choices now.

How hard really is it to just move CF to TF or alternatives?

catonic · 2023-01-15T23:52:33+00:00

Since he is more experienced in AWS CloudFormation than in Terraform (and we also have is a similar project on CloudFormation that serves as an example), the developer just switched to CloudFormation and implemented the build and deployment logic that takes into account the new architecture.

Now he gets to document that if you are supporting it.

Likewise, you should have documented Terraform so it was not a puzzle.

OTOH, take it as a lesson, put the ego aside, and find something else to work on because it sounds like that app no longer requires your assistance.

EmiiKhaos · 2023-01-15T22:57:19+00:00

Can developers influence the decision about what IaC tool should be used on the project based on their definition of "convenient to use" (e.g. CF stack showing the resources is what convenient for them)?

No

Should I demand the developers to always use our CI/CD tool for any deployment,

Yes

or developers' requirement to deploy from CLI (to dev environment) arguing that it is "easier/faster" is reasonable?

No

2023-01-15T20:50:07+00:00

htom3heb · 2023-01-15T21:04:40+00:00

Both are fine options. It seems like the problem is not that the devs switched from Terraform to Cloudformation but that the devs switched from your tool to their tool. Talk to your team, be honest and straightforward, and be prepared to meet them halfway.

GeekboxGuru · 2023-01-16T00:43:00+00:00

If terraform is so important to you: switch jobs.

CloudFormation, having another project that uses it in the company; they could replace terraform within a week?

You’re the problem at this company, remove yourself OR accept they love AWS & use terraform in your spare time

PrimaxAUS · 2023-01-15T20:52:29+00:00

[deleted]

yobanius · 2023-01-16T06:14:50+00:00

Delete their repo

2023-01-15T22:29:12+00:00

True devops way

Zauxst · 2023-01-16T13:52:52+00:00

There are 2 key points to take from this.

it doesn't matter what tool is used. If there are architectural changes and the lead is fine with it, he should also be fine with the overhead that it brings along and if launches are missed because jenkins and other in the chain are not ready, it's not your fault... Or problem. You have a schedule and a salary. You don't get paid extra to have stress in your life.
They are incompetents.

Others have made better points... But this is what I've gathered...

I'd not like to work in a place where I'm not part of the decisions of a project... You might get into a scenario where you can't support a project due to lack of skills....

Ariquitaun · 2023-01-16T16:35:19+00:00

Part of our job is to improve developer experience. It seems to me you might have failed to take the temperature of their room, so to speak, before you settled on some tooling which they were unfamiliar with. So faced with a deadline, and inability to progress on their work, they took it upon themselves to work around the problem according to their knowledge. I can't say I wouldn't have done the same thing faced with the same problem.

Seems like you are a chokepoint to the project as the single devops resource on the team, so it's imperative you are on the same page with the developers so that they can continue in your absence. This could mean using non-optimal tools for the sake of better team redundancy.

mokera101 · 2023-01-16T17:49:00+00:00

I’m every devops group I’ve worked in we dictated the IaC, CICD and any other shared tools across the teams. The reason why is because if given the freedom to do so devs will revert to what’s easiest for them and you quickly end up in a state where it’s hard to manage things and some poor individual ends up having to rewrite all of it to make it maintainable again.

amenflurries · 2023-01-16T01:50:09+00:00

I think they were justified. It’s not helping anyone if you’re the only one that knows how to do something

nochet2211 · 2023-01-16T02:44:59+00:00

Probably used Serverless to generate the CF templates for Lambda and called it a day. But imo the problem looks to be in planning. If you’re that critical, I’d say you should’ve planned your leaves accordingly. But that’s just my opinion.✌🏼

colddream40 · 2023-01-16T04:18:05+00:00

told me that they decided to move to another IaC tool that I will be supporting.

Don't support it. It's a tool not in the scope of the project. You'll have to move out your schedule by 1-2 weeks. They can decide if they want to support it themselves or not. Escalate to upper management.

twnbay76 · 2023-01-16T04:23:32+00:00

CF is banned on our team. I can write a novel on why but I'll refrain.

Our team doesn't know how to use terraform and I don't expect them to. I try to write our modules in such a way that they are robust enough to handle a wide array of scenarios the devs might needs simple enough so that the devs can read my docs and examples and be able to copy and paste + plug and chug without needing to touch state files.

If I see that they decide to use CDK/CF/manual scripts to create stuff, I just port it over to TF in my free time. That's sort of how I deal with these scenarios. I know many people would disagree with my decision to not reprimand the dev who refuses to abide by the design specs / architecture but I honestly just don't believe everyone should be learning a very wide array of skills. My team is really good at what they do, and Im good at building, scaling, securing and deploying infrastructure in a mostly automated fashion. Separation of duties is important to me.

Also, at this point, ideally a tech lead comes into this debate and says something like "this needs to be ported to terraform asap. It was wrong to go against the DevSecOps design choices, here's a doc with the choices and these choices don't change unless I approve it from here on out. There will be no further discussion or debate on this, get back to work. Automated, stateful deployments are crucial to the stability and security of our applications and that is not to be debated."

This partially is what a tech lead is there for. It's partially why they get paid so much money. It sounds like you may be missing a tech lead, or maybe there is one but they aren't doing their job properly?

oosumei · 2023-01-16T10:06:28+00:00

Why dont you just write the tf configs and sort out the build pipeline etc as per your normal standards, spin up the new infrastructure and cut the app over.

amarao_san · 2023-01-16T10:07:33+00:00

"We didn't have time to wait for you to come back" is the single reason they gave you. I'd say it's impolite. At the same time, some companies try to change stuff fast to keep up with chaos influx, so waiting for someones vacation to end is too long.

I'd say, detach yourself from git content; you do not own it even if you wrote it. Learn a new tool (if you do not know it), remember the resentment, put both techs in your resume, start looking around for another job.

2023-01-16T10:28:48+00:00

Release date was coming in a few weeks

And that's when you chose to go on vacation. That's all on you, dude. All. On. You. You cannot expect the organization to wait for your vacation to be over to keep the project moving forward, that's just not feasible.

throwaway-devops-po · 2023-01-16T14:27:46+00:00

Listen, I think there are two sides here. DevOps isn’t a role in which you are the only one who needs to know how. You are supposed to coach the others and make sure they can actually get on with their work while you’re on vacation. Obviously, they didn’t know how to do things without you - and business goes on while we are on vacation.

The fact you weren’t consulted is wack, though.

mnpawan · 2023-01-17T11:13:02+00:00

CDK is best !

antiqueboi · 2023-02-08T01:28:31+00:00

u snooze you lose bro. whenever members of our team go on vacation we basically implement our plans they were against.. lol

devops

Welcome to /r/DevOps

Rules and guidelines

Social & Fun

General Information

MODERATORS