About
Ian Vulovic
I administer IT systems for a living and train for Men's Physique outside of it. They look unrelated. In practice they run on the same method.
The overlap
Two systems, one approach
Both disciplines reward the same behavior. You define a system, run it consistently, measure what it produces, and change one variable at a time when the numbers disagree with the plan. Neither rewards intensity applied at random.
A migration that fails and a training block that stalls fail for similar reasons: an assumption nobody checked, a dependency nobody mapped, or a measurement nobody took. Troubleshooting a mail flow problem and troubleshooting a plateau are the same exercise performed on different equipment.
The other shared property is time. Neither produces results on the timescale people want. Both produce results on the timescale of consistent execution, which is the part most approaches quietly skip.
Background
Technology
Roughly ten years in IT
My work has centered on systems administration in environments built on Microsoft 365 and Google Workspace - identity, email, collaboration platforms, endpoints and the security controls around them, plus the migrations that move all of it from one place to another.
The environments I am most useful in are the ones where those areas are entangled: a change to conditional access breaks a mail connector, an endpoint policy breaks a sharing workflow, and a DNS record that nobody documented breaks everything.
Training
Men's Physique
I train toward the Men's Physique standard: shoulder width, a developed chest and arms, a back with both width and thickness, and the conditioning that makes the proportion visible rather than theoretical.
The program is written in blocks, executed as written, logged every session, and revised on evidence. That is the entire method. It is not complicated, which is exactly why it works.
How I work
What you can expect
-
01
Understand it before changing it
Inventory and dependency mapping first. Most of the damage I get called in to repair came from a reasonable change made without knowing what depended on the thing being changed.
-
02
Write it down
Configuration, rationale and rollback position, recorded where someone else can find them. Undocumented infrastructure belongs to whoever last touched it, which is not a sustainable arrangement for anyone.
-
03
Automate the second occurrence
Once by hand is fine. Twice by hand is a script waiting to be written. Repeatable work should produce identical results regardless of who runs it or how late in the day it is.
-
04
Say what is actually true
Including when the answer is that something will take longer than hoped, or that the proposed fix addresses a symptom rather than the cause. Accurate information is worth more than reassuring information.
The name
Why IAZZUS
IAZZUS is the identity I put on everything I build - the consulting work, the training record, and this site. Keeping it under one name means the professional side and the physical side are not pretending to be separate people.
It also gives the technical work somewhere to live as it grows. The consulting practice, project write-ups and whatever comes after them all belong under the same domain rather than scattered across platforms I do not control.
Work, training, or something else.
The contact form routes by category, so it reaches the right context.