When you freelance in DevOps, saying yes feels like survival. A new client emails, you have a gap in your calendar on paper, and before you know it you are running five small engagements at once, each one a little behind. Freelancers who try to fix this keep asking similar things, and the reply rarely changes: put a limit on how much work in progress you carry as a freelancer, and finish one thing before you take on the next. Let us go through it question by question.
What does “work in progress” actually mean for a freelancer?
It is every task or client commitment you have started and not yet finished. That includes the obvious ones, like a pipeline setup or a cluster upgrade, and the sneaky ones: the quote you promised to send, the call you owe a prospect, the documentation you said you would tidy up afterwards. If someone is waiting on you for it, it is work in progress.
Why does juggling feel productive when it is not?
Because every time you switch, something small gets done and you feel movement. The cost is invisible. Each switch means rereading notes, remembering where you left a script and rebuilding the picture in your head. At the end of the week you have touched many things and delivered few. Clients experience that as slow progress, even though you were busy all day.
How many clients or tasks is the right limit?
There is no magic number. A decent starting point is two active client projects and one small task at a time on top. If your projects are tiny, you might manage three. Try a number for a month, then check whether things are finishing faster. If you keep breaking the limit, it is probably too low or you are secretly being pulled into unpaid extras.
What if a client has an emergency?
Emergencies are real in operations work. Agree up front what counts as one, how you will respond and what it costs. When an emergency arrives, you can bend the limit for a day, but note it and return to the limit afterwards. The point is not to be rigid, only to make exceptions rare enough to notice.
Is turning down work risky for my income?
It is a fair worry, especially at the start. The honest answer is that you are not turning work away so much as scheduling it. A prospect who hears “I can begin on the fifteenth, when my current project wraps up” often says yes. Prospects who need someone this minute are not always the clients you want long term. Many freelancers find that steady, finished engagements lead to referrals, which tend to be the best source of new work.
If you have a day job as well, the pressure is even stronger, which is why the piece on freelancing responsibly next to a full-time role is worth a read. Capping what you have active is a down-to-earth way of keeping both jobs healthy.
How do I say no or later without sounding unprofessional?
Keep it short and specific. Something like: “Thanks for thinking of me. I am wrapping up two projects and can start yours on the twelfth. If that works, I will send a proposal this week.” You have been honest, given a date and avoided overpromising. Most clients appreciate the clarity more than a rushed yes that turns into a missed deadline.
How do I know when something is really finished?
Write your own definition for each type of job. For example, a pipeline job is finished when the client has run it themselves, the handover notes are shared and they have confirmed in writing. A job that is “done on my side” but not accepted is still open, and it still counts against your limit. That one habit prevents a lot of awkward follow-up weeks later.
What should I do with tasks that are waiting on the client?
Put them in a separate waiting list with a date to nudge. A task waiting on credentials, an approval or a test window does not need your attention every day, so it should not hold an active slot. Without this distinction, the limit becomes frustrating, because blocked work seems to eat your capacity.
Can I still learn new things with a limit in place?
Yes. Treat learning as one of your active items, with its own slot, rather than a pile of half-watched courses beside everything else. Finishing one course or lab before opening another makes the knowledge stick. If you are new, the beginner questions every new DevOps freelancer asks are a friendly place to see how others structure their first months.
Is this idea really that general?
It is. People adopt the same habit for household chores, studying and personal projects, and you will find talk about it across all sorts of online communities. A wellness-flavoured example is AskDoctorLive, a site whose public pages feature discussion boards, articles and listings of hospitals and doctors, the kind of place where ordinary routines and habits come up in conversation. You do not need to look there for freelance advice, of course; the point is that finishing before starting is common sense wherever people have too much on.
What should my first week with a limit look like?
- Write down everything that is open, including promises you made in passing.
- Pick the two or three items closest to done and mark them active.
- Move everything else to a waiting or queued list with dates.
- Tell your clients, in a friendly way, when you will start their queued items.
- At the end of the week, count what finished.
Expect the first week to feel a bit strange. You will be tempted to peek at the queued list and to start something small “just to get ahead”. Resist for a few days and see how it feels to deliver rather than juggle.
Any final tips from freelancers who have tried it?
Keep your limit visible, perhaps as a line on a notebook page or a card on a board. Review it monthly. Celebrate closed projects, however small, because finishing is the whole point. A short list of live commitments does not mean business has dried up. It means you pick the order of the work, rather than whoever wrote last.
