[dangus]

DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business (perpetually understaffed) and as “last minute complicated requests that sound simple enough” and “oops our requirements changed” dumping grounds for engineering teams.

Plus, the ops side has a lot of challenges that can really be a different beast compared to the application side. The breadth of knowledge needed for the job is staggering and yet you also need depth in terms of knowing how operating systems and networks work.

[immibis]

> DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business

This is one of those explanations that sounds reasonable but when you actually experience it you realize the explanation makes no sense.

If you're "running behind of technical debt" you'll always feel understaffed no matter how much staffing you have. And adding more staffing will make your tech debt worse.

Plus, tech debt doesn't really exist. It's a metaphor for all the little annoyances in your system that add up, but the metaphor makes it sound like it's the problem of management or accounting to solve when it's actually created by developers and solved by developers.

[dangus]

Hmm, no, you were changing the meaning of my comment.

> no matter how much staffing you have

That’s not what I said. I said that there tends to be not enough staff. Businesses are more willing to hire software engineers (shipping features = revenue) than hiring DevOps people (keeping the lights on).

> tech debt doesn’t really exist.

Well that’s news to me. I’m pretty sure it exists. It has an entire Wikipedia article, and that article doesn’t agree with your definition.

And yes, more staff would help. Hiring me literally helped my organization fix its lack of monitoring and alerting because nobody had time to address the problem during my team’s day to day responsibilities.

Your assertion that it’s not management’s fault is absurd. Management is by definition the bearer if ultimate responsibility. Every problem in any business is something where the buck stops at management.

If I ship something with long term problems because management told me to work faster and meet the deadline, that is directly management’s fault. Even me shipping something bad on my own volition is management‘s fault indirectly: they hired the wrong talent (me), or maybe they assigned me to the wrong project where my expertise wasn’t good enough, or they misjudged risks and didn’t leave enough contingency buffer or didn’t make a plan for what to do if we fail.

The way businesses view humans are as machine-like resources of labor (Human Resources), they don’t view you as an individual with emotions and thoughts and feelings. When they hire someone they have quantitative measures surrounding that person: how likely are they to perform well, burn out and quit, steal from the company, get run over by a bus, etc. The corporate system actually dictates that management is responsible for the way it arranges and commands its human machines.

[Aeolun]

> Plus, the ops side has a lot of challenges that can really be a different beast compared to the application side.

That’s why we aim to call it DevOps, so that you can take all that into account from the start of the project?

[dangus]

In practice, I’ve never seen a “DevOps” or “SRE” team that wasn’t just Ops.

Almost every company works with the “throw stuff over the wall to DevOps” mentality. The word “DevOps” is meaningless.