PurPassionDigital / Everywhere
The landscapeSoftware EngineeringDevOps / Infrastructure Engineer
Software Engineering · Digital / Everywhere

DevOps / Infrastructure Engineer

Unexpected
Organization · Disordered OrderedThe pull to create structure from chaos
Pace
  • A steady rhythm with room to breathe
  • Short, intense, and the stakes are right now
What your week looks likeShifts — mornings, nights, weekends on rotation
How much you move around at workScreen and chair, almost all day
Whether you can work from anywhereWork from anywhere with a signal or internet connection
How quickly you receive feedback on your workYou know within hours
What you're actually working withNumbers, measurements, records — things you read on a screen / Concepts, theories, designs, stories — things you think up

Core
  • Applying systematic problem-solving to make things work reliably.
  • Watching for danger, maintaining vigilance.
  • Building systems that make safety structural, not reactive.
  • Turning chaos into repeatable process.
Also present
  • Making processes run without constant human input.
  • Locating the specific point of failure in a complex system. The detective work of dysfunction.
  • Taking something that works and making it work better.
  • Creating consistency at scale.

You build and maintain the ground that other software runs on — servers, networks, deployment pipelines, monitoring, and security infrastructure, the invisible layer that lets applications exist in the world and not fall over. If developers build the house, you build the foundation, the utilities, and the alarm system. The primary pull is Organization: taking the sprawling, inconsistent way systems get deployed and imposing a coherent, repeatable structure on it, so that shipping software becomes safe and routine rather than risky and improvised.

Protection and Resolution sit right behind that ordering work. Your success is measured largely by things not happening — the service did not go down, the deploy did not break anything, the breach did not occur — which is a particular kind of satisfaction, because the better you are, the less anyone notices. The systems-thinking demand is high: you are not building a single thing but the relationships between many things, designing for load, redundancy, failure modes, and graceful degradation. The mental model is closer to civil engineering than to creative coding.

🦊
There's a guide here if you want one

Kitsune can talk through anything on this page — whether it might suit you, what to do next, questions this page doesn't answer. Everything here is yours to read either way.

You are the person who gets paged at 3am. Infrastructure problems do not wait for business hours, and the on-call rotation is the defining feature of the role rather than an occasional inconvenience. Some organisations handle this well, with reasonable rotations, good tooling, and a no-blame culture; some handle it badly. The on-call experience is the single biggest quality-of-life variable in the role, and it is the thing to ask about in every interview.

The invisibility cuts both ways. Because the work is most visible when it fails, the recognition structure is inverted relative to most building roles — a perfectly run platform generates the absence of complaints rather than praise. The engineers who are happiest here are the ones who find genuine satisfaction in leverage and reliability themselves, rather than in external acknowledgement that rarely comes.

Few people start here; most arrive after time in software development or systems administration, having discovered an interest in the infrastructure layer rather than the application layer. The skill set blends coding, networking, security, and operational discipline, and is developed largely through experience. Cloud-platform certifications exist and can help with hiring, but demonstrated experience running real systems — and handling the incidents that come with them — carries more weight than any single credential.