There is a kind of post I see almost every week. It comes from someone in IT, in sysadmin work, in infrastructure, or in support, who has just landed a job that does not say "DevOps" on the title line. They are slightly apologetic about writing about it. The job is on Linux. There are deployments across multiple environments. They talk to teams every day. But they think it's not DevOps.

This week I read one from a member of our community. He landed a role as an IT Infrastructure Specialist after a long unemployment stretch. The work involves Red Hat, multi-stage deployments, and constant meetings with project teams and clients. Officially, the title is not DevOps. He shared the news anyway, partly to mark the win and partly to ask the question every person in his shoes asks. Am I still on track?

This mail is about the part of DevOps that no other program in the market is actually teaching. There are dozens of courses that will teach you AWS. There are zero, as far as I have seen, that teach you how to run a meeting, communicate with non-technical stakeholders, and convince engineering teams to actually adopt the systems you build. KubeCraft is the only program I know of that teaches both layers, with a real interview guarantee on the other side. If you want the full picture, you can click here to find out more. There are five spots open for this month.

The terminal is the easy part of DevOps work. The hardest part of the job, the one nobody bothers to put in the job description, is convincing other humans to use what you have built.

This took me longer to learn than I would like to admit. I went into DevOps because I loved Linux and thought I would get to code all day. The Kubernetes part turned out to be the fun part. The hard part was the Tuesday morning meeting where I had to explain to a team of developers why their cluster being two minor versions behind was their problem, not something the platform team could fix in silence. None of that was a code problem. It was a persuasion problem dressed up as a technical one.

Every infrastructure project you ship has a strange property. It only counts when other humans actually use it. A pipeline that nobody adopts is a private hobby. A monitoring stack that nobody trusts is decoration. A migration plan that nobody agrees with is an unread document. The technical part of the job outputs an artifact. The human part outputs a decision. Decisions compound and artifacts depreciate.

The shape of the work, if you say it out loud, is something like this. You ship the system. Then you persuade the people who need to use it, often one stakeholder and one engineer at a time. Then you keep their trust so the next time you propose something difficult, they say yes again.

Now the AI panic, because I see that one almost as often. People are scared their DevOps jobs will be eaten by an LLM that can write Terraform. I understand the fear. I also notice that the LLM does not run the meeting. It cannot read the room when the security lead frowns. It cannot earn the trust of an engineer who has been ignored by the infrastructure people for ten years and is now being asked, again, to change his workflow. As the technical layer of the job gets cheaper, the work of dealing with humans becomes more load-bearing, not less.

Back to whoever is reading this with a job title that does not feel quite right. There are two ways to read your current situation. You can read it as a detour, the long way around to a job title you are still chasing. Or you can read it as the actual training ground. In the second reading, every difficult stakeholder conversation is a rep that someone with a clean DevOps title will eventually have to learn the hard way. Every meeting where you have to explain a Linux concept to a non-technical audience is an interview question you are quietly pre-answering. You are becoming the kind of engineer organisations cannot afford to lose, even before you have the title that proves it.

The terminal is the easy part. Convincing the humans is the job.

Mischa

P.S. The work of dealing with humans, the meetings, the stakeholder conversations, the daily task of convincing engineering teams to actually use what you build, is the missing piece of every DevOps program I have looked at. You can get the technical knowledge in a hundred places. KubeCraft is the only program that teaches both layers under one roof, with a real interview guarantee. Complete the work, follow the job-search system, and if you do not have interviews within six months, we keep working with you for free until you do. Applications are reviewed personally. If you read this mail and recognised your own week in it, that is a signal worth acting on. Click here to apply.

​