Freelancers like to say that independence means nobody owns your time. In practice it often means the opposite: every awkward job in your practice lands on you, because you are the entire team. The out-of-hours alert, the late-paying client, the tedious environment clean-up, the support request that comes with a lecture. This checklist helps an independent DevOps freelancer audit those hard jobs, find which ones are quietly draining you, and decide which can be rotated with a small circle of trusted peers rather than carried alone.
The approach is analytical. Instead of relying on how a week felt, you collect a little evidence about it, then act on what the evidence shows.
Step one: list the hard jobs honestly
Open an empty note and jot every repeating chore you dislike or dread. Do not filter. For a freelance DevOps practitioner the list often includes these.
- Being the first responder when a client’s service misbehaves outside working hours.
- Chasing overdue invoices and having the uncomfortable conversation.
- Cleaning up an inherited environment where nothing is documented.
- Handling the one client whose requests change daily.
- Keeping your own tooling, accounts and credentials in order.
Next to each item, write how often it occurs and how you feel afterwards, in a single word. Words such as drained, irritated or fine give you a rough signal that is more honest than a vague sense of busyness.
Step two: gather a fortnight of evidence
For two weeks, keep a simple tally. Each time one of the hard jobs interrupts you, put a mark beside it and note the time of day. Do not try to be precise. The aim is to see which duties are scattered through your evenings and which are clustered in manageable blocks.
Patterns tend to appear quickly. You may find that the out-of-hours alert is rare but disruptive, while the invoice chasing is constant but shallow. Those two deserve completely different answers. The first is a candidate for shared cover. The second is a candidate for better process and perhaps reminders.
Step three: separate duties into three bins
- Keep. Jobs that are rewarding or that only you can do, such as the design conversations with a key client.
- Fix. Jobs that are painful because the process is poor. Automate or simplify them before sharing them.
- Share. Jobs that are inherently unpleasant and recurring, where another competent person could take a turn.
Be careful with the second bin. It is tempting to hand a broken process to someone else and call it a rotation. A fair rotation passes on duties that are clear and bounded, not a mess you have not tidied.
Step four: find your circle
Sharing needs other people, and most freelancers know a few. Two or three reliable peers with similar skills are plenty. Good starting points are former colleagues, people from training courses or contacts from the kinds of networks described in a guide to building a dependable web of freelance contacts and finding mentors. What matters is trust and comparable skill, not a large group.
Agree in writing on what the circle will and will not share. A common arrangement is cover for the first-response duty only. Each person remains responsible for their own client relationships and billing, but when one of you is away or off the clock, a peer takes the first look at an alert and calls you only if something truly needs you. Be explicit about which clients have consented to this, and never share access to a client’s systems without their agreement.
Step five: design the rotation
With a circle of three, a simple weekly cycle works. A few rules keep it fair and sustainable.
- Publish the rota in a shared calendar with a few weeks of lookahead.
- Count heavy weeks as heavier. If someone handled a major outage, they skip the next turn.
- Pair first-time cover with a short walkthrough of each client’s environment.
- Keep a short note after each turn recording what happened and anything the owner should know.
It helps to remember that you are not building a company, only an arrangement of mutual convenience. Keep the paperwork light, but make sure the expectations are written down so no one is surprised.
A worked example: Nandini’s circle
Consider a freelancer called Nandini who supports a handful of small clients. Her fortnight tally showed that overnight alerts were infrequent but almost all fell on weeknights, and that two of her clients accounted for nearly every interruption. She put overnight first response in the share bin and the invoice reminders in the fix bin. She then asked two former colleagues, Farid and Joy, to form a cover circle. Each client agreed in an email thread, and each peer received a short briefing document covering that client’s architecture, contacts and boundaries. After a month, Nandini had slept through most nights, Farid had learned an unfamiliar cloud setup, and Joy had picked up a monitoring habit she then took to her own clients.
Step six: check the evidence again
After a month, repeat your tally. Compare the new marks with the first fortnight. You are looking for fewer disruptions during personal time, shorter recovery after hard days, and a clearer picture of what each client actually needs. Do not expect miracles. A modest improvement in how many evenings you keep to yourself is a real result.
If the numbers do not move, ask why. Perhaps the circle is too small to cover a busy period, or perhaps one of your clients expects you personally and no one else. That is useful information as well, and it may suggest a conversation about expectations when you next renew the work.
Limits worth respecting
A cover circle is not a substitute for a contract that matches the support a client genuinely needs. If a client expects instant response at every hour, be honest about what one person and two friends can promise. Overpromising is the quickest way to turn a friendly arrangement into a resentful one. Review confidentiality terms with each client before any peer touches their systems, and keep a record of who agreed to what. Trust grows when these boundaries are written plainly.
Where a larger operations team fits
Some independent engineers eventually decide that round-the-clock coverage is beyond what a small circle can offer. At that point it is reasonable to know what a dedicated operations team looks like. DevOpsSupport is one such consultancy, supporting teams on cloud operations and DevOps work, and seeing how outfits like it organise their own rota gives a freelancer a handy template whether or not they ever partner with one.
A quick audit checklist you can copy
- I have written down every hard recurring job, with a one-word reaction.
- I have collected at least two weeks of simple tally marks.
- Each duty sits in keep, fix or share.
- I have approached two or three peers whose skills I trust.
- Clients affected by cover have agreed to it.
- The rota is published, with a way to handle heavy weeks.
- Each turn ends with a short note.
- I will repeat the tally in a month.
Anyone who is only now learning how independent work functions can fill the gaps first with plain answers like common questions from people starting out as DevOps freelancers before building any rota at all.
What good looks like
A healthy freelance practice is not one with no hard jobs. It is one where the hard jobs are known, bounded and shared where it makes sense. You can take a weekend without a phone beside your plate. A peer understands your most important client’s setup well enough to keep it steady for a few days. And you, in turn, can do the same for them, which is its own quiet source of professional satisfaction.
Start with the list this week. It costs nothing, takes twenty minutes, and tells you more about your working life than most productivity advice ever will.
