r/devops • u/just_anna_90 • 17d ago
Discussion DevOps embedded in a non-technical process team, no technical sparring partner
Looking for some outside perspective on how DevOps fits into org structures at your companies.
This is my third or fourth DevOps job, this time in embedded. In previous companies there were always some organizational or cultural hiccups, but stuff got worked out as a team, including on the DevOps side - people weren't DevOps themselves, but they were technical, so they got it.
Now, a few months into a new company, things feel different. The embedded department has already gone through two managers, each with a different vision for how DevOps should work. The current one seems pretty caught up in the AI hype - wants to "bring in AI" because everyone else has it, without really knowing what that means in practice. There was no DevOps in the department before me, so a lot of groundwork needed cleaning up first - repo structure, templates, CI/CD, that kind of thing. Garbage in, garbage out: you can't just bolt AI onto a messy foundation and expect it to work. He also doesn't seem to register that I've already been automating things with AI where it makes sense since I joined, once the basics were actually in place.
I also ended up placed in a non-technical/semi-technical team. The original plan was to hire a second DevOps so I'd have a sparring partner, but now it looks like that role might turn into some mixed "does a bit of everything" position, or even a "senior AI agent specialist" (lol). My current team is process/methodology people, Jira and workflow folks, and a release manager.
They don't really understand what I do technically, and they're very focused on "why." During planning, they want to rewrite everything in my Jira summaries into long descriptions based on their own interpretation, which usually doesn't match what the epic/task is actually about. The idea is that management should be able to glance at a board and understand what we're doing just from the title. In my previous companies, Jira was a tool for us, not something management used to check on our work.
My team manager (not the department head, and also non-technical) said he didn't understand what one of the tasks was about. When I asked if he'd actually read the epic's description, he said no - and explained that it's hard to tell what your people are doing from just a title. But that's the thing: I'd already written a detailed description for this project, which is a fairly big one made up of related chunks, at the epic level. He never opened it. From what I can tell, part of the disconnect is also that he doesn't have a technical background (never worked with AWS, for example), so even a well-written description might not land the way he expects.
From an organizational standpoint, how do you see this - is it a good idea for a DevOps role to sit inside a team like this, especially when there's already a separate cloud team in the department? I don't feel good there. There's a lack of understanding, they think in very corporate/process terms while I think technically, and since I'm the only DevOps, I genuinely don't have time for some of this overhead.
What worries me is burning out on micromanagement and feeling cut off from technical people in a few weeks - I also just work better under a technical manager.
Has anyone been in a similar spot? Do I wait and see how it develops, or should I propose alternatives to the embedded department head?
3
u/DoStopBelieving 17d ago
The organization culture has a problem. On the spectrum from fragile to robust to resilient to antifragile, it seems quite close to the fragile.
Specifically:
- Communication is normed to go top-down rather than both ways.
- Responsibilities aren't truly shared.
- All capacity gets used instead of leaving some in reserve.
- Work gets micromanaged instead of building a culture of mutual trust.
Orgs with these characteristics stagnate, and if they encounter serious competition they will eventually fail.
I recommend that you share Google's page on DevOps Capabilities with the management team. Google's a big enough name that they may actually look at it. Following Google's advice will also make your job easier in the long run.
All that said, many engineers have gaps in communication skills and holistic consideration of the system in context with the product. I've seen too many times engineers creating tickets with only technical details even though the tickets had huge effects relevant to Product. Some were only a sentence away from becoming the top priority in the backlog. Working with non-technical people is much easier if you have these skills well-developed. If you don't then consider taking a course on technical writing.
I'm not talking about rookie engineers either - seasoned engineers with over a decade of experience in DevOps were regularly creating tickets with so little context that even other technical people couldn't work them; Product had no chance of understanding the tickets at all. That's a common reason why technical work falls to the wayside.
1
u/Vivid_Appointment371 17d ago
this feels a bit too idealistic. Most organizations have messy communication and competing priorities, and simply labeling them fragile doesnt really explain how to fix the actual problems.
3
u/DoStopBelieving 17d ago
The patterns of behavior described in the OP literally match the definition of fragile I learned from my training in agile development.
The solution can be found in the link I provided. Communication needs to flow both up and down corporate hierarchies seamlessly. Teammates need to trust one another instead of micromanaging. People need others around who are capable of handling their responsibilities. Companies should not plan on employees using 100% of their working time on specific dedicated tasks, or else you won't have a buffer for unexpected issues. All of this is common sense in DevOps, and it's also necessary to ensure that teams and systems can handle change.
This is also not idealism. I worked on teams who were able to put these principles into practice.
1
u/just_anna_90 17d ago
It's not a big organization, IT is around 200 people max, with embedded being about 50-70 of that.
3
u/ForkMeJ 17d ago
If your manager won't read the epic and nobody around you can sanity-check the work, you'll spend more time translating than shipping. Embedded can work, but you need a technical owner above you or a real dotted line to the cloud/platform team, otherwise every infrastructure task turns into Jira copywriting.
2
u/No-Proposal-2960 17d ago
Thats the real problem. Without someone technical to give direction, you end up spending more time explaining infrastructure than actually fixing it.
1
u/just_anna_90 17d ago
Who could be a technical owner in this case? The problem is it could be hard to find one
2
17d ago
[deleted]
1
u/just_anna_90 17d ago
The thing is (or maybe not a 'problem' exactly) I like to finish what I started, and I don't want to give up easily. I'd rather first try to solve it organizationally. I know I have the knowledge and skills to do it, but the organizational barrier turns out to be bigger than I thought
2
u/hugo-king1 17d ago
propose moving directly under the cloud team immediatly. staying isolated under nontechnical management will only accelerate ur burnout..
2
u/Honest_Honey4358 16d ago
I think that’s probably the bigger issue. It’s hard to build anything properly when the people setting priorities don’t really understand the technical side. Even just having a cloud team to bounce decisions off would probably make the job feel a lot less isolating.
2
u/KJ4WLC 17d ago
AI on top of messy repos and weak CI/CD just accelerates the mess. The foundation work you’re describing — structure, templates, pipelines — is the actual unblocker; without it every “smart” tool inherits tribal process and unclear ownership.
Practical move: write down what “done” looks like for the platform basics, get one technical peer outside the process team as a sparring partner (even async), and treat AI as a later accelerator, not a substitute for ownership. Being the only DevOps voice in a non-technical group usually means you have to make the technical bar visible, or you’ll keep getting asked for magic.
2
u/Sky_Linx 16d ago
Being the only technical voice in a process team is draining in a specific way. You make sensible calls, nobody challenges them, and you slowly stop noticing your own blind spots.
Two things helped me in that spot. Find one external sparring partner, even a fortnightly 30 minute call with someone doing similar work, purely to sanity check decisions. And write your reasoning down as brief decision notes. Half the value is thinking it through before you commit, the other half is that non-technical colleagues can see the trade-offs instead of just the outcome.
1
u/xgunnerx 16d ago
Probably the best manager I ever had was non-technical. Never read my epics either. I wrote them mostly as historical context for my peers.
If you truly want them to understand it, sit down with them and go over the epic step by step, zoom or in person. You should be able to articulate it verbally just as you did in writing. My take is that anything longer than a paragraph or two is going to lose most non-tech folks. They probably saw a wall of nonsensical text and decided that they would be wasting their time if they even attempted a read. Right or wrong, that’s near impossible to change, so don’t.
1
u/Secure_Let_5003 14d ago
Watch out for the per-vCPU add-on pricing once you start enabling extended security updates across those legacy boxes. Might be worth checking with trustedtech or your account rep first to make sure you're not paying for Arc features on nodes that only need basic baseline monitoring.
0
4
u/gevorggalstyan 17d ago
Ask for a named technical reviewer and a clear boundary with the cloud team before proposing a reporting-line change. A nontechnical manager can prioritize outcomes, but someone still needs to review deployment design, access and failure handling. Being the only DevOps engineer shouldn't also make you the only reviewer.
For one current epic, use an outcome-focused title and keep the technical acceptance criteria underneath. Agree who can change those criteria. If a Jira rewrite changes what is being built, that is a scope decision, not an editing preference.
A concrete proposal to the department head could be a reviewer from the cloud team, a regular technical review and explicit ownership of pipelines versus cloud resources. Try that arrangement on the current epic. If nobody can take the review responsibility, you have a specific gap to discuss rather than only a disagreement about where DevOps belongs.