HACKER Q&A
📣 throw_devops_q

How do you manage your IT/DevOps role?


Context: I'm senior mostly-solo IC for a mid-sized SaaS that does DevOps and IT-related tasks.

This role is similar to others I've had in the past. It's great because there's lots of flexibility and not much micromanagement.

It's challenging because:

- I often need to learn and evaluate new products (e.g some SaaS we might want to use). On a related note it's often difficult to get good (sometimes any) support for products we're paying for, so I waste time debugging obscure issues or reading through confusing documentation

- I don't really have anyone to delegate to. I could coordinate with managers to negotiate for engineers' time, but this would take almost as long as just doing some of the tasks myself, so I don't do this

- Verification is difficult. Infrastructure doesn't have as good testing facilities as "regular" software does, and even when it does that still takes some setup, which must be balanced against everything else I'm supposed to be doing and the new things that come up.

- I often am asking for review for people not on my (mostly solo) team, which can take time and extra reminders

- I mostly get requests from everywhere, manage my own backlog, and people are busy enough that they really only see what they need to remind me to do (because there's a lot to do), rather than all the little things I get done

This is better than previous similar roles I've had, as the teams are nicer and I don't own everything I touch, but I feel I'm falling behind and will not get recognition unless I "sell" my accomplishments (which of course I don't have time to do anyway).

I don't really feel I can turn work down, and don't really care to, but I'm finding it difficult to get it all done and still work a regular amount of hours.

It's also difficult to ask for help, as in the past when I've asked for training I've been told things like "ohh that's not too hard", which is generally true for most products once you've got the hang of them, but never getting training on anything is a recipe for lots of half-baked solutions, or lots of time off the clock reading and experimenting.

I worry trying to define my role will lead to micromanagement. I worry not doing so will lead to burnout or me missing things. I worry discussing these issues with management or fellow engineers will make me look incompetent or unwilling to do my job. I also worry it's going to get increasingly difficult to advance in this role, as the more I do the more I'll be asked to look into, and with things being difficult to test/verify, the small tasks will continue to pile up as I try to work on the large tasks.

How have you handled this situation in the past, other DevOps/IT folks?

I added in IT because I'm also given administrative tasks as needed (migrating some accounts/debugging issues that aren't strictly software related).


  👤 azmarks Accepted Answer ✓
You need to push to get 1-2 junior devops engineers that you can handle the day-to-day tasks (unblocking engineers, fixing common issues), so that you can focus on larger picture tasks (evaluating new technologies, setting strategies, etc.). The story you need to sell is that investment in devops will make all the other engineers faster (better CI/CD, less manual work, etc). And that only having a single devops engineer limits the amount of unblocking that you can do (which will slow down engineers) and leave no coverage when you go on vacation (and you should be going on vacations).

The goal is to identify common problems and have junior engineers fixing them and working with you on how to automate your way out of that problem. And you are setting the devops future plan. What are the tasks/technologies you need to do and how will it speed up the developers? And that's what you need to sell, speeding up developers and making their development life easier.


👤 valyagolev
about self-management:

I've been finding myself in similar roles, and one thing to keep in mind is that the constant feeling of not being productive enough is rarely helpful. So focus on your real output and consider it as already enough.

If you're the only one person in this role and you have to manage yourself, it means you're quite indispensable and you should start to define your own process that would be good for your real productivity and sensible and legible to the whole company.

It might sounds scary, but actually such a step very often ends up being quite welcome by everyone around, who are now have much better idea of your real availability and can have an input into real, not imaginary, prioritisation of your work.

Not sure about the reviews, though. Never figured that one out for solo in the role. However, after you start self-managing it's much easier for the management to notice when you need some help. Then someone gets hired and you have a reviewer around.


👤 atmosx
> This role is similar to others I've had in the past. It's great because there's lots of flexibility and not much micromanagement.

...is there _lots of flexibility_ ? Looks like you're stuck between the hammer and the anvil to me. You either kill yourself or the backlog grows forever, to top it all you don't seem to be getting much appreciation...

Company's should be pushing you to get trainings, not the other way around.

The market is hot for SRE/DevOps, especially if you have experience with kubernetes/swarm/nomad and cloud providers (AWS, GCP, Azure, etc.), I think you should move on. Look for a company that has an infrastructure _team_ to join. Will be a lot more fun.


👤 edmcnulty101
You desperately need a ticketing system like Trello or another Kanban. Have people (and yourself) file tickets for all work items. Line up the tickets you're going to work on this week to give yourself 40-50 hours of work. Now you have something to show other people on teams, managers, etc and a document of your work.

All new work needs to go through the ticketing system and all new work needs a priority attached to it.

Every Monday you plan out your work for the week and line up higher priority tickets first.

If something immediate comes up during the week, you put a ticket out and bring the new item in.


👤 dpkirchner
> I don't really have anyone to delegate to. I could coordinate with managers to negotiate for engineers' time, but this would take almost as long as just doing some of the tasks myself, so I don't do this

I think this could be worth exploring. It may take more time the first N tasks, but maybe along the way you'll find an engineer that is really good, or at least is interested in transitioning to a devops-based role. It could be an easy way to grow your team.